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NATIONAL FOREWORD 

This Indian Standard which is identical with ISO 21214 : 2006 'Intelligent transport systems — Continuous air 
interface, long and medium range (CALM) — Infra-red systems' issued by the International Organization for 
Standardization (ISO) was adopted by the Bureau of Indian Standards on the recommendation of the Automotive 
Electrical Equipments and Instruments Sectional Committee and approval of the Transport Engineering Division 
Council. 

The text of the ISO Standard has been approved as suitable for publication as an Indian Standard without 
deviations. Certain conventions are, however, not identical to those used in Indian Standards. Attention is 
particularly drawn to the following: 

a) Wherever the words 'International Standard' appear referring to this standard, they should be read as 
'Indian Standard'. 

b) Comma (,) has been used as a decimal marker while in Indian Standards, the current practice is to 
use a point (.) as the decimal marker. 

In this adopted standard, rGference appears to the following International Standard tor which Indian Standard 
also exists. The corresponding Indian Standard which is to be substituted in its place is given below along 
with its degree of equivalence for the edition indicated: 



International Standard 

lEC 60050-845 Jnternational 
Electrotechnical Vocabulary — Lighting 



Corresponding Indian Standard 

IS 1885 (Part 16/Sec 1) : 1968 
Electrotechnical vocabulary: Part 16 
Lighting, Section 1 General aspects 



Degree of Equivalence 
Technically Equivalent 



The technical committee responsible for the preparation of this standard has reviewed the provisions of the 
following International Standards including those under preparation referred in this adopted standard has 
decided that they are acceptable for use in conjunction with this standard: 



International Standard 



Title 



ISO/IEC 8802-11 



ISO/CD 21 21 0-1 

ISO/CD 21210-2 

ISO/CD 21 21 7 
ISO/CD 21 21 8 
lEC 60825-1 



Information technology — Telectommunications and information exchange 
between systems — Local and metropolitan area networks — Specific 
requirements — Part 1 1 : Wireless LAN Medium Access Control (MAC) and 
Physical Layer (PHY) specifications 

CALM (Communication Air-interface Long and Medium range) Networking 
Protocols — Part 1 : CALM Networking for Internet Connectivity 

CALM (Communication Air-interface Long and Medium range) Networking 
Protocols — Part 2 : CALM Networking for Direct Mode Connectivity 

Communications, Air-interface, Long and Medium Range (CALM) —Architecture 

CALM Common Station Manager (Lower Level SAPs) 

Safety of laser products — Part 1 : Equipment classification, requirements and 
user's guide 
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Introduction 

This International Standard is part of a family of International Standards for CALM (continuous air interface, 
long and medium range) which determine a common architecture, network protocols and air-interface 
definitions for wireless communications using cellular second generation, cellular third generation, 5 GHz, 
millimetre, and infra-red communications. Other air interfaces may be added at a later date. These air 
interfaces are designed to provide parameters and protocols for broadcast, point/point, vehicle/vehicle, and 
vehicle/point communications in the ITS sector. 

This International Standard determines the air interface using infra-red systems operating in the wavelength 
range at 850 nm. 

The fast movement of information across the longer distances using wireless technology is functionally very 
different from the requirements definition for dedicated short range communication (DSRC). High volumes of 
data are required for purposes such as traffic information and management, video downloads to vehicles for 
tourist information and entertainment and navigation system updates, etc. 

In order to support such services, transmitters need to be able to operate over long or medium range, and to 
be able to nand over a session from one transmitter to another, 

These International Standards are designed to enable quasi-continuous communications, or communications 
of protracted duration, between vehicles and service providers, or between vehicles. As such they are 
complementary to dedicated short range, single point, technologies standardised in various regions of the 
world. 

The CALM concept supports multiple bearer types (such as cellular, microwave, infra-red), where an option is 
proposed to offer user selection of preferred media, and to enable resumption of session interruptions 
(whether to change bearer media, service provider, or because of signal interruption or interference). 

Some applications will have the requirement that communication sessions set up in a first communication 
zone may be continued in following communication zones; therefore "handover mechanisms" are included. 
Handover mechanisms need to be defined at two levels: 

— Firstly, handover mechanisms within the same technology and service provider. These handover 
mechanisms are defined within the frequency-specific CALM International Standards. 

— Secondly, handover mechanisms at the application level, for use where either the technology or the 
service provider changes. These handover mechanisms will be defined within the CALM architecture 
International Standard (ISO 21217), within the CALM networking protocols International Standard 
(ISO 21210) and within the CALM lower layer SAP International Standard (ISO 21218). 

Applications include the update of roadside telemetry and messaging, internet, image and video transfer, 
infotainment, traffic management, monitoring and enforcement in mobile situations, route guidance, car-to-car 
safety messaging, maintenance management, and "yellow page" services. For medium- and iong-range high- 
speed roadside/vehicle transactions such as on-board web access, broadcast and subscription services, 
entertainment, yellow page and booking transactions, etc., the functional characteristics of such systems 
require contact over significantly longer distance than is feasible or desirable for DSRC, and often for 
significantly longer connection periods - in some circumstances, continuous communication. 



IV 
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Indian Standard 

INTELLIGENT TRANSPORT SYSTEMS — 

CONTINUOUS AIR INTERFACE, LONG AND MEDIUM 

RANGE (CALM) — INFRA-RED SYSTEMS 

1 Scope 

This International Standard determines the air interface using infra-red systems at 820 nm to 1 010 nm. 

It provides protocols and parameters for medium-range, medium- to high-speed wireless communications in 
the ITS sector using infra-red systems. 

Such links are required for quasi-continuous, prolonged or short communications 

— between vehicles and the roadside, 

— between vehicles, and 

— between mobile equipment and fixed infrastructure points, 
over medium and long ranges. 

Vehicles may be moving or stationary. 

Wherever practicable, this International Standard has been developed by reference to suitable extant 
International Standards, adopted by selection. Required regional variations are provided. 

Due account is given to, and use made of, any relevant parts of appropriate communications systems, such 
as global positioning systems (GPS), digital audio broadcasting (DAB), digital video broadcasting (DVB), radio 
local area networks (RLANs), digital data broadcasting (DDB), TETRA, FM subcarrier, mobile broadband 
systems (MBS, W-ATM), internet protocols, and dedicated short range communication (DSRC). 

The International Standard: 

— supports data rates of 1 Mbit/s up to 128 Mbit/s (it may support higher data rates); 

— supports vehicle speeds up to a minimum of 200 km/h (closing speeds could be double this value); 

— defines or references environmental parameters relevant to link operation; 

— supports communication distances up to 100 m (it may support longer communication distances of 300 m 
to 1 000 m); 

— supports latencies and communication delays in the order of milliseconds; 

— is compliant to regional/national regulatory parameters; 

— may support other regional/national parameters as applicable. 

Application-specific requirements are outside the scope of this International Standard. These requirements will 
be defined in the CALM management and upper layer standards and in application standards. 

Application-specific upper layers are not included in this International Standard, but will be driven by 
application standards (which may not be technology specific). 
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2 Conformance 

Systems claiming conformance v/ith this International Standard shall meet the specifications herein. 

3 Normative references 

The following referenced documents are indispensable for the application of this document. For dated 
references, only the edition cited applies. For undated references, the latest edition of the referenced 
document (including any amendments) applies. 

iSO/1 EC 8802-11, Information technology — Telecommunications and information exchange between 
systems — Local and metropolitan area networks — Specific requirements — Part 11: Wireless LAN Medium 
Access Control (MAC) and Physical Layer (PHY) specifications 

I EC 60050-845, International Electrotechnical Vocabulary. Lighting 

I EC 60825-1, Safety of laser products — Part 1: Equipment classification, requirements and user's guide 

4 Terms and definitions 

For the purposes of this document, the following terms and definitions apply. 

4.1 General 

4.1.1 

broadcast window 

BcW 

window used to broadcast information to slaves, even to those which have not yet performed the "registration 
process" 

4.1.2 
chip 

smallest information unit communicated over the link 

NOTE Depending on the chosen coding, one information bit may be represented by one or more consecutive chips. 

4.1.3 

communication profile 

specific set of data rate, modulation and flow control 

4.1.4 
communication zone 

spatial zone in which two CALM-IR units are able to communicate with acceptable performance 

4.1.5 

compatibility window 

CmpW 

enables non-CALM-IR systems that follow certain rules to co-exist with a CALM-IR system without harmful 
interference 

4.1.6 

default data rate 

data rate used in the "default communications profile" 



13 15754:2006 
180 21214:2006 

4.1.7 

default communications profile 

communications profile used unless another communications profile is successfully negotiated 

4.1.8 
flush byte 

8 bit sequence used to denote the end of the main body of the information to be transmitted using the 
HHH(1,13) coding procedure 

4.1.9 

forward direction 

communication flow from master to slave 

EXAMPLES forward link, fonward window 

4.1.10 

frame length indicator 

Flen 

indicator is used to calculate the frame length from the last "slot index" 

4.1.11 

frame organisation table 

FOT 

table which carries all organisation data of the TDMA frame 

4.1.12 

free airtime indicator 

FATI 

indicator which signals that "free airtime" follows the current frame 

NOTE This airtime may be used by units not being a slave of the current master to establish "secondary mastership". 

4.1,13 
guard time 

Tg 

time period preceding a "command alert" (CA) in certain cases in order to allow the automatic gain control of 

the receivers to resettle 

4.1.14 
HHH(1,13) code 

special run length limited code with d= 1 and /t= 13 used in the CALM-IR communications profiles 2 to 6 

4.1.15 

management window 

first window in a CALM-IR frame, which carries all organisation information for the current frame 

4.1.16 

master identifier 

MID 

code which uniquely identifies a CALM-IR master 

4.1.17 

multicast window 

McW 

window used for communication from master to multiple slaves, forward direction only 

4.1.18 

private window 

window which carries the information exchange between a master and a specific slave 
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4.1.19 
registration phase 

phase during which a master identifies devices newly entering its communication zone 

4.1.20 
slave 

device that is under the control of another device 

4.1.21 

spare window 

SpW 

window, not allocated to a slave, which reserves airtime for any slaves registering during the current frame in 
order to enable the master to instantly allocate them a private window without the need for frame 
reorganisation 

4.1.22 
slot index 

index used to count time slots 

4.1.23 
TDMA frame 

time (division multiple access) structure based on a train of consecutive time slots (at least one) 

4.1.24 
time slot 

subunit of a TDMA frame 

4.1.25 

temporary identifier 

7emp/D 

identifier used for addressing the slave device while it resides in the communication environment of the master 

NOTE Each time the slave registers in a communication zone, a new TempID is created. 

4.1.26 

wake-up window 

WuW 

special case of a broadcast window which is used to "wake-up" sleeping units entering the communication 
zone of an active master 

4.1.27 
window 

smallest addressable time span of a CALM-IR frame which may consist of one or multiple time slots 

4.2 Optical parmeters 

4.2.1 

radiant power 

radiant flux 

power emitted, transmitted or received in the form of radiation 

NOTE 1 The unit is the watt (W). 

NOTE 2 Adapted from lEC 60050 (845-01 -24). 
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4.2.2 

radiant intensity 

quotient of the radiant flux JOg leaving the source and propagated in the element of solid angle «^ containing 
the given direction, by the element of solid angle 



^ dn 

NOTE 1 Unit: W/sr (watts per steradian). 

NOTE 2 Adapted from lEC 60050 (845-01-30). 

4.2.3 
irradiance 

quotient of the radiant flux </0q incident on an element of a surface containing a given point divided by the 
area dA of that element 

NOTE 1 Unit: W/m2. 

NOTE 2 Equivalent definition. Integral, taken over the hemisphere visible from the given point, of the expression 
Z-e cos6'dn . where Lg is the radiance at the given point in the various directions of the incident elementary beams of 
solid angle dQ, and d is the angle between any of these beams and the normal to the surface at the given point. 

E^^— f- = l2„srLe cose- dCl 
dA 

NOTE 3 Adapted from lEC 60050 (845-01 -37). 

4.2.4 

radiant exitance 

We 

quotient of the radiant flux rfOg leaving an element of a surface containing a given point divided by the area dA 

of that element 

NOTE 1 Unit: W/m2. 

NOTE 2 Equivalent definition. Integral, taken over the hemisphere visible from the given point, of the expression, where 
Le cxsse dQ. is the radiance at the given point in the various directions of the emitted elementary beams of solid angle 
dn, and e is the angle between any of these beams and the normal to the surface at the given point. 

Me = — — = l2;rsr ^e COS^ ■ dO. 
dA 

NOTE 3 Adapted from lEC 60050 (845-01 -47). 

4.2.5 
radiance 

quantity (in a given direction, at a given point of a real or imaginary surface) (igi L) defined by the formula 



® dAcose-dn 
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where 

c^Og is the radiant flux transmitted by an elementary beam passing through the given point and 
propagating in the soiid angle dD. containing the given direction; 

d'i is the area of a section of that beam containing the given point; 

is the angle between the normal to that section and the direction of the beam. 

NOTE 1 Unit: W/srm^. 

NOTE 2 Adapted from lEC 60050 (845-01-34). 

4.2.6 

radiant intensity 

quotient of the radiant flux d<^g leaving the source and propagated in the element of solid angle dn containing 
the given direction divided by the element of solid angle 

NOTE Adapted from I EC 60050 (845-01-30). 

4.2.7 

steradian 

SP 

dimensionless SI unit of solid angle 

NOTE 1 The steradian is the solid angle of a cone which, having its vertex in the centre of a sphere, cuts off on the 
surface of the sphere an area equal to that of a square with sides of length equal to the radius of the sphere. 
[150 31-1:1992. 1-2.a] 

NOTE 2 Usually the abbreviation "sr" is appended, although mathematically this is incorrect. 

EXAMPLE 

The unity solid angle, in terms of geometry, is the angle subtended at the centre of a sphere by an area on its surface 
numerically equal to the square of the radius (see Figure 1). Other than the figure might suggest, the shape of the area 
does not matter at all. Any shape on the surface of the sphere that holds the same area will define a solid angle of the 
same size. 

0<»4ictr 




iXtmr 



Kt»9jy 



Figure 1 — Solid angle 
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Relation between distance ^ irradiance E^ and Intensity /g 

Using a single radiation point source, we get the following relation: 



dOe Iq dQ Iq 
dA ~ dA r^' 



W 



2 
m 



NOTE 3 Adapted from lEC 60050 (845-01-20). 

4.2.8 
luminous flux 

quantity derived from radiant flux <l>^ by evaluating the radiation according to its action upon the CIE standard 
photometric observer, for photopic vision 



where 

dA 
is the spectral distribution of the radiant flux and F(/l) Is the spectral luminous efficiency 
NOTE 1 For the values K^ (photopic vision) and K'^ (scotopic vision), see lEC 60050 (845-01-56). 
NOTE 2 Adapted from lEC 60050 (845-01 -25). 

4.2.9 

luminous efficacy of radiation 

K 

quotient of the luminous flux O^ divided by the corresponding radiant flux Og 

*e 
NOTE 1 When applied to monochromatic radiation, the maximum value of K{X) is denoted by the symbol K^ 
K^ = 683 lm.W-1 for v^ = 540 x 10^2 Hz {A^ « 555 nm) for photopic vision. 
K'm = 1700 lm.W-1 for A'^ = 507 nm for scotopic vision. 
For other wavelengths, K{A) = K'^ V(A) and K\X) = K'^ V\X). 

NOTE 2 Adapted from lEC 60050 (845-01 -55). 



m- 
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5 Symbols and abbreviated terms 

For the purposes of this document, the following symbols and abbreviated terms apply. 



BcW 


broadcast window 




CALM 


continuous air interface, long and medium range 




CFA 


CALM-fast application 




CME 


CALM management entity 




CmpW 


compatibility window 




CRC 


cyclic redundancy check 




D 


beam axis, "bore-sight direction" 




DAB 


digital audio broadcasting 




DDB 


digital data broadcasting 




DVB 


digital video broadcasting 




DSRC 


dedicated short range communication 




^e 


irradiance 




£v 


illuminance 




FATl 


free airtime indicator 




FB 


flush byte 




FOR 


fast-CALM infra-red packet format 




FM 


frequency modulation 




IPv6 


internet protocol version 6 




MID 


frame length indicator 




FOT 


frame organisation table 




F-Sync 


frame synchronisation signal 




HHH 


Hirt, Hassner, Heise (inventors of the HHH(1, 13) code) 




/e 


radiant intensity 




IR-CAL 


infra-red communication adaptation layer 




IRfMAE 


infra-red management adaptation entity 




IR-ME 


infra-red management entity 




K 


luminous efficacy of radiation 




Le 


radiance 




LLC 


logical link control 




MAC 


medium access control (sometimes used as a synonym for MAC 


layer) 


McW 


multicast window 




Me 


radiant exitance 




MID 


master identifier 




MnW 


management window 




^'frame 


number of time slots in a CALM-IR frame 




'^frame.max 


maximum number of time slots in a CALM-IR frame 




'^frame.min 


minimum number of timesiots in a CALM-IR frame 




OBU 


on-board unit 
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PA 

PL 

PP 

PDU 

PrW 

RLL 

RSU 

SAP 

SpW 

sr 

STA 

STO 

T 
'chip 

^CWAIT 
TDMA 

^DREG 

TempID 
TETRA 

^F-Sync 



' Pfall 

^Pon 

^Prise 

^REG 

^RT 

^RW 

^RWAIT 
^TempID 
W-ATM 

W-Sync 

WuW 

A 

&y 
9 



preamble 

payioad 

preamble period 

protocol data unit 

private window 

run length limited code 

roadside unit 

service access point 

spare window 

steradian 

start flag 

stop flag 

bit time (duration of one bit) 

chip time (duration of one chip) 

waiting time of the slave for a reply to a proposed TempID 

time division multiple access 

registration time-out 

temporary ID 

trans-European trunked radio access (an ETSl standard for trunked radio networks) 

duration of the F-Sync signal 

guard time 

lead time — time from the rising edge of the last pulse of a synchronisation signal 
{F-Sync, W-Sync, CA) to the rising edge of the first pulse of the following command, etc. 

optical pulse fall time 

optical pulse on time 

optical pulse rise time 

delay time before slave replies to a MC-RRQ or MC-REN 

waiting time of the master for a reply to its MC-IDP 

receiver window - time span around the allocated time slot when the receiver circuit 
shall be ready to detect a W-Sync signal 

waiting time of the master for a reply to a MC-RRQ or MC-REN 

TempID time-out. 

wireless asynchronous transfer mode 

window synchronisation pattern 

wake-up window 

elevation angle 

horizontal opening angle 

vertical opening angle 

azimuth angle 

radiant power, radiant flux 

luminous power or luminous flux 
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6 Requirements: transmitter and receiver parameters 
6.1 Transmitter wavelengths and bandwidths 

Table 1 — Infra-red transmitter parameter specification 



Parameter name 


Specification 

Channel 870 Channel 970 
(main channel) (alternate channel) 


TX1 


1 — — ■ 

Nominal transmitter wavelength 


870 nm 


970 nm 


TX2 


Transmitter pass band 


820 nm to910 nm 


920 nm to 1 010 nm 


TX3 


Coherence length 


< 1 mm 


TX4 


Total radiated power 


dependent on transmitter class (see 6.2) 


TX5 


Minimum receiver in-band (RX2) radiated power 


80 % of TX4 


TX6a 


Radiated power below pass band 


not specified 


< 10% of 7X4 


TK6b 


Radiated power above pass band 


< 10 % of 7X4 


not specified 



NOTE Regarding parameter 7X3: 



'c 

where 
'c 

X 

AX 

EXAMPLE 



AA 

is the coherence length; 
is the wavelength; 
is the bandwidth. 

X = 900 nm, AX = 40 nm 



{900 nm)' 



20 ^Jm 



40 nm 

6.2 Radiated power 
6.2.1 Radiated power limits 

Table 2 — Infra-red transmitter parameter limits 



Parameter name 


Specification 


7X7 


Maximum radiated intensity 


According to lEC 60825-1 


7X8 


Maximum transmitted power within the 
range of visible light 


Not limited by this International Standard^ 


^ Certain automotive standards may have limitations on this parameter. 
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6.2.2 Transmitter classes 



The transmitter class shall be declared in the associated product specification and shall be organised as 
shown in Table 3. 

Table 3 — Transmitter classes 



Parameter 


T1 


T2 


T3 


T4 


T5 


T6 


T7 


T8 


TX class 

T9 |t10 


Til 


T12 


T13 


T14 


T15 


T16 


TX4a- 

Minimum radiant intensity [W/sr] 

(pulse peak value) 


0,36 


0,75 


1.5 


3 


6 


12 


25 


50 


100 


200 


400 


800 


1600 


3200 


6400 


12800 



6.3 Receiver wavelengths and bandwidths 

Table 4 — IR receiver parameter specification 



Parameter name 


Specif 

Channel 870 
(main channel) 

mandatory 


cation 

Channel 970 
(alternate channel) 

optional 


RX1 


Nominal receiver wavelength 


870 nm 


970 nm 


RX2 


Receiver pass band 


835 nm to 905 nm^ 


935 nm to 1 005 nm 


RX4a 


Lower receiver stop band 


< 805 nm 


905 nm 


RX4b 


Upper receiver stop band 


^ 935 nm^ 


^ 1 035 nm 


RX5a 


Receiver sensitivity in lower stop band 


not specified 


^ 10 dB above RX6 


RX5b 


Receiver sensitivity in upper stop band 


^ 10 dB above /?X6*^ 


not specified 


^ Receivers which are able to receive both channels employ an upper limit of 1 005 nm. 
^ Receivers which are able to receive both channels employ an upper limit of 1 035 nm. 
^ Not specified for receivers which are able to receive both channels. 



The manufacturer shall declare whether he implemented in the equipment only the mandatory main channel 
or as well the optional alternate channel. 
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6.4 Receiver class 

The receiver class shall be declared in the associated product specification and shall be organised as follows: 

Table 5 — Receiver classes 



Parameter 


R1 


R2 


R3 


R4 


RX class 

R5 R6 


R7 


R8 


R9 


RIO 


R11 


RX6 [mW/m2] 

Receiver sensitivity 
in boresight 

@ RX2, RXd, RX9 
an6RX11 


better 

than 

32 


better 

than 

16 


better 

than 

8 


better 

than 

4 


better 

than 

2 


better 

than 

1 


better 
than 
0.5 


better 
than 
0,25 


better 

than 

0,12 


better 

than 

0,06 


better 

than 

0,03 


RX7 [mW/m2] 

Saturation limit in 
boresight 


12 800 


6 400 


3 200 


1 600 


800 


400 


200 


100 


48 


24 


<12 


RX8 

Reference bit error 
ratio (B.E.R.) 


10-6 


RX9 

Immunity to 
interference caused 
by natural optical 
radiation 


5= 1 120 W/m2 (sunlight spectral distribution) 


RX10 [mW/m2] 

Wake-up sensitivity 
in boresight 
@ 500 kHz 


better 

than 

32 


better 

than 

16 


better 

than 

8 


better 
than 

4 


better 

than 

2 


better 
than 

1 


better 
than 
0,5 


better 

than 

0,25 


better 

than 

0,12 


better 

than 

0,08 


better 

than 

0,03 


RX11 

Reference 

communication 

profile 


Default communication profile 



The manufacturer shall declare the guaranteed sensitivity for all communication profiles implemented in the 
equipment. 
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7 Modulation and coding 

7.1 Generic modulation parameters 

7.1.1 Wake-up signal 

in systems where receivers which have a "sleeping mode" are to be expected, the master has to send a 
"wal<e-up signal" in order to wake-up any "sleeping" slaves. The wake-up signal is to be transmitted in a 
"wake-up window". 



Time slot 



Figure 2 — Wake-up signal 
Table 6 — Wake-up signal timing specification 



Parameter name 


Specification 


TX11 


Wake-up signal 


Burst frequency: 500 kHz ± 1 %, duty cycle: 45 % to 55 % 


TX12a 


Max. allowed pulse rise time (optical) 


200 ns 


TX12b 


Max. allowed pulse fall time (optical) 


200 ns 



7.1 .2 Transmitter generic modulation parameters 

Table 7 — Infra-red transmitter parameter TX10 specification 



Parameter name 


Specification 


TX10 


Tolerance of bit clock 


0.1% 



7.1 .3 Receiver generic modulation parameters 

Table 8 — infra-red receiver parameter RX12 specification 



Parameter name 


Specification 


RX12 


Tolerance of bit clock 


0.1% 


NOTE "Tracking" of the receiver clock or equivalent techniques are assumed in the sync, modes. 



7.2 Communications profiles 

CALM IR employs a whole set of data rates and coding schemes, which have to be selected in dependence of 
the application and of the actual link quality. 

Specific data rates and coding schemes constitute a "communications profile". 

The profiles given in Table 9 apply. 
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Table 9 


— Communications profiles 






Parameter 




(base 
profile) 


1 

(default 
profile) 


2 


Profile 

3 


4 


5 


6 


Data rate 


1 Mb/s 


2 Mb/s 


8 Mb/s 


16 Mb/s 


32 Mb/s 


64 Mb/s 


128 Mb/s 


Modulation 


3/16 
OOK-RZ 


6/16 
OOK-RZ 


CIR-8 

HHH(1, 13) 


CIR-16 
HHH(1,13) 


CIR'32 
HHH(1, 13) 


CIR-64 
HHH(1, 13) 


CIR-128 

HHH(1,13) 


Bit time Fbi, 


1 000 ris 
±1 % 


500 ns 

±1 % 


n.a. 


Chip time, r^ip 


1 000 ns 

±1 % 


500 ns 
±1 % 


83,4 ns 
± 6,6 ns 


41.7 ns 
±3,3 ns 


20,8 ns 
± 1,6 ns 


10,4 ns 


5,2 ns 


Optical pulse on 
time, 7p„, 


190 ns 
±20ns 


190 ns 
±20ns 


83,4 ns 
+ 6,6 ns 


41,7 ns 
+ 3,3 ns 


20,8 ns 
± 1,6 ns 


10.4 ns 


5,2 ns 


Optical pulse 
rise time^, Tp^^ 


«75 


«75 


< 38 ns 


fc 19 ns 


^ 9 ns 


to be added 


to be added 


Optical pulse fall 


<75 


<75 


< 38 ns 


s^ 19 ns 


:§ 9 ns 


to be added 


to be added 


Format 


Sync. 


MAC flow 
control 


By MAC commands 
("Block start", "Block end", "Packet start", "Packet end", 'Start of control-block"). 


Forward error 
correction 


Hamming Z,= 12,D = 3'' 


none'' 


Multiple error 
detection 


Hamming z,= 12, D-3'' 


CRC32 


NOTE Some of the parametere of profile 5 and profile 6 will be defined in future versions of this Internationa! Standard. 


^ Equipment employing several communications profiles shall conform with the most stringent values, irrelevant which profile is 
active at a given time. 

^ For details see Annex B. 



Further profiles may be added in the future. 

7.3 Profile (base profile) and profile 1 (default profile) modulation 



DO Dt 



D2 D3 



IL 



04 



u 



D5 



D6 D7 






ECO ECl EC2 EC 3 

I I I 



li 



D8L: DataByt« I.«ii4|tl> 



Figure 3 — Modulation of profiles and 1 

The coding and decoding rules for the communications profiles and 1 are defined in Annex A. 
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7.4 Profiles 2 to 6 

Profiles 2 to 6 do not employ forward error correction. 

NOTE Burst errors at these dataspeeds are much more likely than single bit errors. 

Burst errors are detected by the CRC. 

The complete coding and decoding rules for the communications profiles 2 to 6 (e.g. modulation types CIR-8 
to CIR-128) are given in Annex B. 
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8 Directivity and communication zones 

8.1 Directivity parameters 

For a directional communication with CALM-IR devices, a three-dimensional co-ordinate system (;«:calM' 
>'CALM' ^calm) has to be constituted. The origin of the co-ordinate system corresponds to the source of the 
beam. The x-axis of the CALM-device corresponds to the forward direction of the vehicle. 

Figure 4 shows the azimuth angle (p and the elevation angle 6 of the beam axis D ("bore-sight direction") in 
relation to the x-axis ("main direction"). 



■2'CALM J, 




CALM 



"/calm 

Figure 4 — Azimuth and elevation angle of the beam axis 

Further parameters of directivity are the horizontal opening angle &^ and the vertical opening angle 0^ ^^ 
detailed in Figure 5. 







■Yd 




^-Yd 



Figure 5 — Horizontal opening and vertical opening angles 

Azimuth and elevation are measured according to Figure 4. 

Openings are symmetrical to the beam axis D. 

Valid horizontal openings &^ encompass values from degrees to 360 degrees. 

Valid vertical openings 0y encompass values from 0" to 360'. 

The resolution of these angles is ©basic ("" ''■S")- 
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8.2 Communication zones 

8.2.1 Basic beam 

A "basic beam" is defined as a beam (in arbitrary direction) with the minimum possible horizontal and vertical 
opening angles equal to the resolution ©basic - '^ '^°- 

8.2.2 Communication zone construction 

8.2.2.1 A CALM-IR communication zone with any "footprint" on the sphere "illuminated" by the "antenna 
array" may be defined by assigning a number of basic beams being a member of It. 

Alternatively a CALM-IR communication zone with a regular, i.e. symmetrical, footprint may be defined by its 
associated directivity parameters: azimuth (p, elevation 6, horizontal opening 0^. and vertical opening 6\/. 

8.2.2.2 Any communication zone may be assigned a specific transmitter or receiver class Independently 
from any other. The assignment of transmitter and receiver classes to communication zones is dynamically 
controllable. 

8.2.2.3 Inside the communication zone, the transmitter class and the receiver class parameters as 
defined in Tables 2, 3, 4 and 5 apply. 

NOTE 1 Any communication zone may be associated with the same "communications channel", thus carrying Identical 
communications streams. 

NOTE 2 Alternatively any communication zone may be associated with a different "communications channel", thus 
carrying different communications streams, independent of each other (dynamically controllable). 

NOTE 3 Isolation between multiple communication zones is not defined by this International Standard. 
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8.2.3 Communication zone sliortcuts 

Shortcuts to speed up the direction control for predefined communication zones are defined in Tables 10 and 1 1 . 

Table 10 — Transmitter communication zones shortcuts 



Zone 


n 


Parar 

S 

n 


neter 

11 




FG 


Forward general 





30 


90 


90 


FS 


Forward straight 








7,5 


7,5 


FR 


Forward right 


-18 





9 


7,5 


FL 


Forward left 


18 





9 


7.5 


BG 


Backward general 


180 


30 


90 


90 


BS 


Backward straight 


180 





7.5 


7,5 


BR 


Backward right 


-156 





21 


7,5 


BL 


Backward left 


156 





21 


7,5 


GR 


General right 


-90 


30 


90 


90 


SR 


Side right 


-45 





15 


7,5 


UR 


Up right 


-60 


36 


21 


21 


GL 


General left 


90 


30 


90 


90 


SL 


Side left 


45 





15 


7,5 


UL 


Up left 


60 


36 


21 


21 


HS 


Hemispheric 





90 


210 


210 


US 


Up straight 





42 


21 


21 


DR 


Disk-radiator 








360 


7,5 
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Table 11 — Receiver communication zones shortcuts 



Zone 


n 


ParaiT 

S 

n 


leter 

n 


0v 

n 


FG 


Forward general 





30 


90 


90 


FS 


Forward straight 








7,5 


7.5 


FR 


Forward right 


-18 





9 


7,5 


FL 


Forward left 


18 





9 


7.5 


BG 


Backward general 


180 


30 


90 


90 


BS 


Baclward straight 


180 





7.5 


7,5 


BR 


Backward right 


-156 





21 


7.5 


BL 


Backward left 


156 





21 


7.5 


GR 


General right 


-90 


30 


90 


90 


SR 


Side right 


-45 





15 


7.5 


UR 


Up right 


-60 


36 


21 


21 


GL 


General left 


90 


30 


90 


90 


SL 


Side left 


45 





15 


7.5 


UL 


Up left 


60 


36 


21 


21 


HS 


Hemispheric 





90 


210 


210 


US 


Up straight 





42 


21 


21 


DR 


Disk-radiator 








360 


7.5 



NOTE For the RSU, no connmunication zone is defined because it depends strongly on the geographical site. 
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9 Frames and windows 

9.1 General structure 

Clause 9 defines the CALM-IR framing, tiie window structure and window management. 

The framing describes the CALM-IR TDMA scheme as a media access method for synchronised 
communication of multiple communication partners. 

In one communication environment with two or more communication partners, there shall exist exactly one 
master, which controls the organisation of the TDMA sequence. 

If no dedicated master exists, a procedure is provided to establish a new master. 

Direct "slave to slave" communications require that one of the slaves act as a temporary master. 

The CALM-IR frame consists of A-frame ^'"^^ s'°^s ^nd is defined and organised by the master. 

The framing structure is defined by reserved signals which by definition can never occur in a data stream. This 
allows simple detection circuitry without the necessity to constantly supervise and analyse the data stream. 

The following signals are used: 

— F-Sync - frame synchronisation signal; 

— W-Sync - window synchronisation signal; 

— CA - command alert. 

The patterns and the use of these signals are described and defined in the following sub-clauses. 

9.2 Frame 

9.2.1 Frame structure 

A frame employs the following characteristics. 

— The CALM-IR TDMA frame is generated by the master and starts with the F-Sync signal. 

— The frame is either terminated by the F-Sync signal of the consecutive frame or, in the event that the 
option "free airtime" is used, with a W-Sync signal and the MAC command "free airtime" {MC-FAT). 

— A frame is subdivided into time slots of duration ^s- 

— The maximum length of the frame is A'frgmemax ^'"^^ s'^^^- ^^^ minimum length is Aframe.min- 

— A frame is organised in "windows" by means of window synchronisation signals, W-Sync. 

— The CALM-IR TDMA frame contains at least one window. 

— The maximum number of windows within one frame is a dynamic parameter and depends on the size of 
the windows. 

— The very first window of a frame is always the management window, MnW. 
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MnW 



Pr\N^ 



REG 



wi 



PrW2 



PrWZ PrW4 PrWn 



l~l~- 



McW and/or 
BcW 



J I I I I I I 1 i I I I t i l-J.. 

2 4 6 8 10 12 14 



.1 I I 1 I..J I 



N-4 N-2 N 

Slot index 



Figure 6 — An example CALM-IR frame structure 
9.2.2 Frame synchronisation signal {F-Sync) 

The frame synchronisation signal F-Sync is generated by the master at the beginning of a frame and has the 
pattern shown in Figure 6. 



IF-Sync, lead 



!L 



_n_rLn 






Tp-Sync 



Start of new frama 



1 k h: h fell #;h"i}r 



First Byte of M/7W=(M/0) 



Figure 7 — Frame synchronisation signal (F-Sync) 

Al! active slaves not in a "transmit state" shall be ready to recognise an F-Sync at all times as an F-Sync can 
also interrupt frames in progress, for example to prioritise emergency messages. 

An F-Sync shall never be sent directly after a "receive state" of the master. In such a case, a guard interval of 
duration Tq shall be inserted before the sending of F-Sync in order to allow the receiver circuitry of all slaves 

to resettle. 

9.3 Windows 

9.3.1 Window structure and types 

9.3.1.1 Frames are subdivided into communication windows by the window synchronisation signal W-Sync 
sent by the master. 

9.3.1.2 Windows may carry forward information (master to slave) as well as return information (slave to 
master). 

9.3.1.3 There exist the following types of window, which are defined in subsequent sub-clauses; 

— management window, MnW; 

— private window, PrW; 

— multicast window, McW; 
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— broadcast window, BcW\ 

— compatibility window, CmpW', 

— spare window, SpW; 

— wake-up window, WuW. 

9.3.1.4 The information flow within a window is controlled by MAC commands and can also be 
interrupted, in case of high priority events, by the communications partner employing the "right to send" 
(Token) using the signal command alert (CA) followed by a MAC command. 

9.3.2 Window synchronisation {W-Sync) 

9.3.2.1 The window synchronisation signal W-Sync is sent by the master at the beginning of all windows 
PrW, BcW, McW and WulA^ except the first window of the TDMA frame which is marked by the F-Sync. 

9.3.2.2 Because of sometimes significant propagation delay times of the signal arriving from the slaves, it 
may happen that the master transmits the W-Sync even whilst still in the receive state. This is not allowed. 
Therefore the W-Sync may be transmitted slightly asynchronously with respect to the time slot index. 

9.3.2.3 In order to account for this effect on the receiver side, the receiver circuitry shall be ready to 
detect the W-Sync not just at the beginning of the time slot allocated by the FOT, but from slightly before until 
slightly after the allocated time within the W-Sync receiver window, T^^^^^^^q. 



I 



Expected start of the window (t = 0) 

m TwTreceive , 



/ WTtransmit 



Figure 8 — Window synchronisation {W-Sync) receiver and transmitter window 

9.3.2.4 In the event that a system is configured with the feature "free airtime", the very last window (which 
may be either a MnW, a PrW, a McW or a BcW) shall be followed by a W-Sync and the MAC command MC- 

FAT. 



I SP 



W-Sync. lead 



rui 



start of window 



I t- ■< It ll ft Kit !t 

I II II It ii ti II II If 
^ I ^' " 11 n II 



T-L 



Tw-Sync 



MAC command 



Figure 9 — Window synchronisation (W-Sync) 

9.3.2.5 A W-Sync never shall follow directly after a "receive state". In such case a guard interval of 
duration Tq shall be inserted before the sending of W-Sync in order to allow the receiver circuitry of the 
communications partner to resettle. 

9.3.3 Management window 

9.3.3.1 The management window {MnW) is the first window in a CALM-IR frame and carries all 
organisation information for the current frame as described below. 
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9.3.3.2 The following occur within the management window. 

— Slaves newly entering the communication zone are registered and allocated appropriate window 
parameters. 

— Sufficient communication time is dynamically allocated to each slave. 

— Care is taken that timing requirements for time-critical applications are met. 

— Care is taken that required command response/reaction times are met. 

— . If necessary, time slots are re-arranged. 

— Short broadcast messages are sent. 

In the management window only the default communications profile shall be used. 

9.3.3.3 The MnW follows Immediately after the F-Sync signal. It is subdivided into the generic frame 
information, i.e. MID, MID and FATI, and optional MAC commands for registration (MC-REG) and organisation 
{MC-FOT, MC-FOTU, MC-FOT S, MC-SUS, MC-SUA); see Clause 12. The generic frame information is 
defined as follows. 

9.3.3.4 The master identifier MID is the unique identifier of any CALM-IR communications master. It 
consists of a three byte integer which is composed of two parts. 

9.3.3.4.1 The first part, the one byte class identity, gives information about the master: fixed roadside 
beacon, vehicle onboard unit, mobile enforcement, PDA or laptop, point-to-point link, etc. 



MSB Bit 6 



Bits 



Bit 4 



Bits Bit 2 Biti LSB 



M F1 FO S K3 K2 K1 KO 

1 Function of the master Sub-master Kind of master 



Figure 10 — Structure of the class identity code 



Table 12 — Class identity codes 



Bit Position 


Value 


Meaning 


Description 


M 


1 


Master identifier 


Used in MAC address to distinguish slaves and masters 


F1, FO 


1, 1 


Broadcaster 


Indicates that the sender of the MID is a "broadcaster" 
only (for example a "talking traffic sign". The broadcaster 
supports no registration of slaves. 


1,0 


Master 


Indicates a normal master to which slaves may register 


0, 1 


Pre master 


Indicates a (normally mobile) unit which, besides being a 
slave to a master, can also assume the function of a 
master (usually of a moving cluster). 


0,0 


Internet access point 


Indicates that the internet is accessible via the master 


S 


1 


Flag: Active as 
secondary master 


Indicates that the unit currently performs two functions at 
the same time: 

it works as a slave versus a master (usually 

positioned in the infrastructure); 

it works as secondary master, usually of a moving 

cluster. 







Flag: Active as master 


indicates that the unit currently works as the master of a 
usually moving cluster. 

In case this cluster comes into the communications zone 
of a master the unit assumes the function of a slave 
versus the master and as a secondary master versus the 
cluster and sets the flag to 1 . 


K3, K2, K1, KO j 


reserved for future use 


If not used, set to 
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9.3.3.4.2 The second part is a 16 bit binary number which, 

— in the event of a stationary master, shall be a fixed number identifying the master and is assigned during 
installation time; 

— in the event of a temporary master, shall be a random number created by the device which wants to take 
the master function. 

9.3.3.5 The frame length indicator MID gives the total length of the current frame in terms of available 
time slots as a one byte integer. 

9.3.3.6 The free airtime indicator FATI gives the airtime following the last window of the current frame 
which is not used by the current master in order to allow other masters to build up a communications frame 
between two frames of the current master. The free airtime is given in terms of the number of time slots 
unused by the current master between two consecutive frames as a single byte integer. 

CALM-IR Frame Free Air Time CALM-IR Frame 

w ■.-■— »i K- ►>»- 



'111 y i s 
n il ^ 1^ 



Figure 11 — Example of free airtime 

9.3.3.7 The coding and modulation during the management window is always according to the default 

profile. 

9.3.4 Private window 

9.3.4.1 Private windows carry the information exchange between a master and a specific slave. Private 
windows are allocated to a master/slave relation by using a temporary MAC Address called "temporary 
identifier" (TempID) which is created during the registration process and "published" in the FOT during the 
management window. 

9.3.4.2 One slave may use more than one private window (PrW). To do this it must register again and a 
new TempID will be created and allocated to it. 

9.3.4.3 Communications in a PrW starts by using the default communications profile. Upon negotiation 
with the master, any communications profile which both master and slave support, and which gives sufficient 
link quality, may be used for subsequent information exchange. 

9.3.4.4 A PrVV employs at least one information transfer phase in the "forward direction" and zero or more 
information transfer phases in the "return direction". 

9.3.4.5 Each PrW starts immediately after the window synchronisation signal W-Sync emitted by the 
master. 

9.3.4.6 The window phase now starting transfers information from the master to the slave ("forward 
direction"). 

9.3.4.6.1 Immediately after the synchronisation signal W-Sync, the master sends, 

— in the event that a new message is to be transmitted, an appropriate MAC command; 

— in the event that the information to be transferred is the remainder of an earlier message which did not fit 
in the slave's last PrW, the MAC command "packet start" {MC-PAS). 
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9.3.4.6.2 The length of the information stream is signalled 

— either inherently by the MAC command itself, or 

— if the length is not inherently given by the MAC command, 

— in the event that all the information which is to be transmitted fits in the current windovtf, by the MAC 
command "block end" {MC-BLE) after the data; 

— in the event that all the information which is to be transmitted does not fit in the current window and 
will be continued in a further PrW of the slave, by the MAC command "packet end" (MC-PAE) after 
the data. 

NOTE All MAC commands which do not start immediately after a W-Sync have to be preceded by a command alert 
signal CA. 

9.3.4.7 Now that the (first) transfer in the fonward direction (master to slave) is finished, the (first) transfer 
from slave to master (return direction) starts. 

9.3.4.7.1 After the recognition of the end of reception (described above), the slave has to wait a "guard 
time" Tq before it starts sending (this guard time allows the receiver on the other end of the link to re-establish 
correct thresholds). 

9.3.4.7.2 The slave then sends an appropriate MAG command (preceded by a command alert CA). 

9.3.4.7.3 The slave then transfers information towards the master (in the "return direction") in exactly the 
same manner as described above for the "fonvard direction". 

9.3.4.8 Where the pre-assigned window size allows, the slave switches to its "receive state" and the 
master may again send information to the slave. 

9.3.4.8.1 In such a case, the master starts the second transfer in the "forward direction" by waiting the 
guard time Tq and issuing an appropriate MAC command. 

9.3.4.8.2 The further sequence is identical to that described above, until the window time expires or until 
none of the partners wants to exchange any more information. 

9.3.5 Broadcast window 

9.3.5.1 Broadcast windows (BcW) are used to broadcast information to all staves within the 
communication zone of the "broadcaster", even to those which have not yet performed the "registration 
process". 

NOTE Unregistered slaves can also receive and decode the FOT, and thus decode the frame and receive the 

broadcast window. 

9.3.5.1.1 A frame shall contain zero or one broadcast window. 

9.3.5.1.2 The broadcast window is addressed by a reserved TempID (see 11.2) in the frame organisation 

table FOT. 

9.3.5.1.3 The broadcast window can have any position in the frame. 

9.3.5.1.4 The broadcast window BcW employs only one information transfer phase, namely in "fonward 

direction". 

9.3.5.1.5 In the BcW the default profile shall be used. 
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9.3.5.1.6 The BcW starts immediately after the window synchronisation signal W-Sync emitted by the 
master. 

9.3.5.1.7 The window phase now starting transfers information from the master to the slave(s) ("forward 
direction"). 

9.3.5.2 Immediately after the synchronisation signal W-Sync the master sends either 

— the MAC command "block start" {MC-BLS) in case a new broadcast message is to be broadcasted, or 

— the MAC command "packet start" (MC-PAS) if the following information is the continuation of an earlier 
broadcast message which did not fit in a single window. 

9.3.5.3 The length of the information stream is signalled either 

— ■ by the subsequent MAC command "block end" (MC-BLE) in the event that all the information which is to 
be broadcasted fitted in the current window, or 

— by the subsequent MAC command "packet end" (MC-PAE) in the event that all the information which is to 
be broadcasted does not fit in the current window and will be continued In a further broadcast window. 

NOTE All MAC commands which do not start immediately after a W-Sync have to be preceded by a command alert 
signal CA. 

9.3.5.4 As the slaves shall not respond in a BcW, the information transfer phase is now finished. 

9.3.6 Multicast window 

9.3.6.1 Multicast windows are used to transfer information to a certain group of registered slaves (within 
the communication zone of the "multicast") which had been included in that group. 

NOTE Procedures on how slaves are assigned to "multicast groups" are not defined in this International Standard. 

9.3.6.2 Multicast windows are addressed by one of the reserved TemplDs allocated to multicasting 
(see 1 1 .2) in the frame organisation table FOT. 

9.3.6.3 A multicast window /WclV employs only information transfer phases in the "forward direction". 

9.3.6.4 In a McW, the communications profile which is set with the first MAC command of the multicast 
window shall be used (see below). 

9.3.6.5 The multicast window McW starts immediately after the window synchronisation signal W-Sync 
emitted by the master. 

9.3.6.6 The window phase now starting transfers information from the master to the slave(s) ("fonward 
direction"). 

9.3.6.6.1 Immediately after the synchronisation signal W-Sync, the master shall send, in each McW, the 
MAC command "set multicast profile" {MC-SMP) in order to signal to the slaves with which communications 
profile the information will be sent. 

9.3.6.6.2 Subsequently, the master sends either 

— the MAC command "block start" {MC-BLS) in case a new multicast message is to be sent, or 

— the MAC command "packet start" (PAS) if the following information is the continuation of an earlier 
multicast message which did not fit in a single window. 

NOTE All MAC commands which do not start immediately after a W-Sync have to be preceded by a command alert 
signal CA. 
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9.3.6.6.3 The length of the information stream is signalled either 



— by the subsequent MAC command "block end" (MC-BLE) in the event that all the infomiation which is to 
be multicasted fitted in the current window, or 

— by the subsequent MAC command "packet end" (MC-PAE) if the information which is to be multicasted 
does not fit in the current window and will be continued in a further multicast window. 

9.3.6.7 As slaves shall not respond in a McW, the information transfer phase is now finished. 

9.3.7 Spare window 

9.3.7.1 Spare windows {SpW) are used to reserve airtime for any slaves registering during the current 
frame in order to enable the master to instantly allocate them a private window without the need for frame 
reorganisation. 

9.3.7.2 SpW start with a W-Sync addressed by a reserved TempID (see 1 1 .2). 

9.3.7.3 The maximum number of SpW in a frame is set in the master by the system administration. 

9.3.8 Compatibility window 

9.3.8.1 A compatibility window {CmpW) may be inserted into a frame in order to enable non-CALM-IR 
systems which observe certain rules to co-exist without harmful interference with a CALM-IR system. 

9.3.8.2 The CmpW starts with a W-Sync addressed by a reserved TempID. 

NOTE This allows CALM-IR units to recognise the compatibility window in a frame and thus do not use it themselves 
for any reason. 

9.3.8.3 No CALM-IR unit shall use the CmpWfor information transfers, etc. 

9.3.8.4 The CmpW may consist of one or multiple time slots. The number of time slots depends on the 
properties of the non-CALM-IR system to be considered and is set in the master by the system administration. 

9.3.8.5 The proper use of a CmpW is explained in Annex E. 

9.3.9 Wake-up window 

9.3.9.1 A wake-up window {WuW) is used to broadcast the wake-up signal pattern (see 7.1.1) in order to 
activate "sleeping" slaves in the communication area of the master. 

9.3.9.2 The WuW starts with a W-Sync addressed by a reserved TempID. 

9.3.9.3 The wake-up signal follows directly after the W-Sync. 

9.3.9.4 The wake-up window may consist of one or multiple time slots. The number of time slots of the 
wake-up window depends on the properties of the OBU population of the system and is set in the master by 
the system administration. 

9.3.9.5 The wake-up window is terminated by the next F-Sync or W-Sync. 

9.4 Command alert {CA) 

9.4.1 Command alerts provide the possibility to interrupt current communications for immediate signalling of 
high prioritised messages (e.g. emergency situation). 

9.4.2 Command alerts can be initiated from both master and slave devices. 



27 



15 15754:2006 
ISO 21214 : 2006 



9.4.2.1 A CA within an MnW can be sent only by the master and is dedicated to all slaves, even to the 
unregistered ones. 

9.4.2.2 A CA within an McW is sent only by the master and is dedicated only to the active slaves. 

9.4.2.3 A CA within a PrW may be sent by either the master or by the slave that "owns" the window and 
is dedicated only to the communications partner. 

9.4.2.4 A CA shall, with one exception defined in 9.4.2.5, be sent only if the originating communications 
partner has the right to send. 

9.4.2.5 If in the "receiving state" the signal is lost, the sending of a CA may be enforced. 

9.4.2.6 In the event that the intended sending of a CA is preceded by a "receive state", the CA shall be 
preceded by a guard time Tq. 

_ ^ Start of command 
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Figure 12 — Command alert {CA) 
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9.5 Summary 

Table 13 summarises the frame and window parameters. 



Table 13 — Frame and window parameters 



Parameter name 


Description 


Value 


Remark 1 


Frame parameters | 


'^frame,rnax 


IVIaximum number of time slots per frame 


256 


Refer to 9.2.2 


Ts 


Length of one time slot 


256 ns 




Tg 


Guard time when changing from receive state to 
send state 


5 000 ns 


This guard time shall always 
be obeyed when a device 
changes from the receive 
state to the send state 


Frame synchronisation | 


F-Sync 


Frame synchronisation signal pattern 




Refer to 9.2.2 


^F-Svnc 


Total length of F-Sync 


7 500 ns 




'^F-S/nclead 


Number of leader pulses in F-Sync 


2 


Refer to 9.2.2 


^P-Svnc,trail 


Number of trailer pulses in F-Sync 


1 


Refer to 9.2.2 


Ion 


On time of leader and trailer pulses 


190 ns 




F-sync.leaa 


Time between F-Sync leader pulses 


500 ns 


From rising edge of 1*' pulse 
to rising edge of second 
pulse 


^F-Svnc 


Number of synchronisation pulses 


4 




Tjl 


Time from last leader pulse to first synchronisation 
pulse 


1 000 ns 


From rising edge of last 
leader pulse to rising edge of 
first synchronisation pulse 


Tl 


Time from last synchronisation pulse to trailer 
pulse 


2 500 ns 


From rising edge of last 
synchronisation pulse to 
rising edge of trailer pulse 


^SP 


On time of synchronisation pulse 


500 ns 




^P 


Time between two synchronisation pulses 


1 000 ns 


From rising edge to rising 
edge 


Window parameters 


window, max 


Maximum number of time slots per window 


256 1 1 


Window synchronisation 


W-Sync 


Window synchronisation signal pattern 




Refer to 9.3.2 


"^WTlransmil 


W-Sync detect tolerance, sender 


-8 05... +20 ns 


The master shall start to 
send the W-Sync signal not 
earlier or not later than this 
time with reference to the 
window's start time allocated 
in the management window 


T 

' WTreceive 


W-Sync detect tolerance, receiver 


-16 ns... +32 05 


The slave shall be ready to 
detect the W-Sync signal 
within this time window with 
reference to the window's 
start time allocated in the 
management window 


^W-Sync 


Total length of W-Sync 


6 500 ns 




^W-Synclead 


Number of leader pulses in W-Sync 


2 


Refer to 93.2 
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Table 13 {continued) 



Parameter name 


Description 


Value 


Remark 


^W-SyncMaS 


Number of trailer pulses in W-Sync 


1 


Refer to 9.3.2 


hoN 


On time of leader and trailer pulses 


190 ns 




^lV-Sync,!ead 


Time between W-Sync leader pulses 


500 ns 


From rising edge of first 
pulse to rising edge of 
second pulse 


^W-Sync 


Number of synchronisation pulses 


3 




h 


Time from last synchronisation pulse to trailer 
pulse 


2 500 ns 


From rising edge of last 
synchronisation pulse to 
rising edge of trailer pulse 


hp 


On time of synchronisation pulse 


500 ns 




Tp 


Time between two synchronisation pulses 


1 000 ns 


From rising edge to rising 
edge 


Command alert 


CA 


Command alert pattern 




Refer to 9.4 


^C» 


Total length of CA 


5 500 ns 




^W.lead 


Number of leader pulses in CA 


2 


Refer to 9.4 


^CA.1m\ 


Number of trailer pulses in CA 


1 


Refer to 9.4 


^LON 


On time of leader pulses 


190 ns 




^C/\,lead 


Time between CA leader pulses 


500 ns 


From rising edge of first 
pulse to rising edge of 
second pulse 


^CA 


Number of CA pulses 


2 




h 


Time from last CA pulse to trailer pulse 


2 500 ns 


From rising edge of last, 
synchronisation pulse to 
rising edge of trailer pulse 


^TL 


Time from last leader pulse to first CA pulse 


1 000 ns 


From rising edge of last 
leader pulse to rising edge of 
first CA pulse 


^SP 


On time of CA pulse 


500 ns 




Time-out j 


^TempIO 


TempID time-out 


255 


Measured in number of 
consecutive frames tn which 
the slave did not respond 
although not being 
suspended 


^DREG 


Registration time-out 


60s 


Measured in seconds since 
the last frame in which 
communications took place 
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10 MAC commands 

10.1 General 

10.1.1 MAC commands are a special signalling mechanism between peer entities of the MAC layer of 

CALM-IR. 

10.1.2 MAC commands may be initiated 

— on request of the infra-red communication adaptation layer IR-CAL, see 14.2 

— on request of the infra-red management adaptation entity IR-MAE. see 14.3, or 

— on request of the infra-red management entity IR-ME, see Clause 1 3. 

10.1.3 A MAC command is always preceded 

— by a command alert (CA), or 

— by a window sync (W-Sync). 

10.1.4 Any MAC command which is sent directly following the "receive state" shall be preceded by a guard 
interval of duration Tq before starting sending. This guard interval allows the receiver on the other end of the 
link to re-establish correct threshold levels. 

10.1.5 A MAC command has a minimum length of one byte and may be followed by an optional attribute, the 
length of which depends on the MAC command. 

Optional payload data shall directly follow the attribute of the relevant MAC command or, if there is no attribute, 
the MAC command. 

10.1.6 MAC commands and their attributes always use the data rate, modulation and coding of the default 
communications profile. 

10.1.7 For payload data, the valid communications profile is used, i.e. either the default communications 
profile or a negotiated and agreed communications profile. 

10.2 MAC commands related to the frame and window organisation 
10.2.1 frame organisation table {MC-FOT) 

10.2.1.1 Function 

The command MC-FOT indicates that the table following the command contains the frame organisation table 
FOT. 

It shall be used in the M/71V only. 

10.2.1.2 Semantics of the service primitive 

/WC-FOT {FOT length} 



Attribute 



F07 length 



Description 



2 bytes provide the total length of the FOT in number of bytes. 



31 



18 15754:2006 
180 21214:2006 

MC-FOT is immediately followed by the table containing the FOT. 

Table 14 — Structure of the frame organisation table (FOT) 



Length 


Meaning 


Description 


2 byte 


TemplD_^ 


Entry of slave 1 


1 byte 


Start slot index of w/indow 




2 byte 


TemplDJZ 


Entry o1 slave 2 


1 byte 


Start slot index of window 


(indicates at the same time the end of window 1) 


2 byte 


TemplD_Z 


Entry of slave 3 


1 byte 


Start slot index of window 


(indicates at the same time the end of window 2) 






Entries of further slaves 










2 byte 


TemplDj] 


Entry of last slave 


1 byte 


Start slot index of window 


(indicates at the same time the end of the last but one window) 


2 byte 


Dummy-ID ^ 


Reserved TempID (see 1 1 .2) 


1 byte 1 Slot index of last time slot 


(indicates the end of the last window) 


NOTE The last entry of the FOT does not relate to any of the slaves in the communication zone of the master, but is 
used only to have a placeholder to signal the length of the last window in the list. 


^ The value of the Dummy-ID is a "Reserved TempID" which shall not be able to be generated during the registration 
process by any slave. 



10.2.2 When generated 

10.2.2.1 This command is generated by the MAC after the end of the registration phase in the event that 
slaves have changed from "registered" to "not registered" or vice versa, and the number of these changes 
exceeds a limit, or the window timing needs to be re-arranged. 

10.2.2.2 If fewer slaves have changed status, the command MC-FOTU shall be used in order to save 
frame time. 

10.2.2.3 The limit between the use of MC-FOT and MC-FOT U is at the discretion of system administration. 

10.2.3 Effect on receipt 

10.2.3.1 On receipt of this command, the slave uses the window with a start and stop time slot as 
indicated in the FOT for subsequent communication. 

10.2.3.2 The receiving MAC shall enable the detection of a window synchronisation signal W-Sync in the 
appropriate time interval defined in the FOT and shall interpret the allocated window as its private window, 
broadcast window or multicast window. 
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10.2.4 frame organisation table update {MC-FOT U) 

10.2.4.1 Function 

The frame organisation table update F07U announces changes of the timing information that have occurred 
since the last reception of an MC-FOT or MC-FOT U. 

It shall be used in the MnW only. 

10.2.4.2 Semantics of the service primitive 

MC-FOT 1/{F07U length} 



Attribute 



FOm length 



Description 



1 byte provides the total length of the FOTU in number of bytes. 



MC-FOT U is immediately followed by the table containing the F07\J. 



Table 15 — Structure of the FOJU 



Length 


Meaning 


Description 


2 byte 


TemplDJ 


Entry for slave "i" which shall 
change its window position 


1 byte 


Start slot index of window 




1 byte 


Stop slot index of window 




2 byte 


TemplD_k 


Entry for slave "k" which shall 
change its window position 


1byte 


Start slot index of window 




1 byte 


Stop slot index of window 





10.2.4.3 When generated 

10.2.4.3.1 This command is generated by the MAC after the end of the registration phase in the event that 
slaves have changed from "registered" to "not registered" or vice versa, and the number of these changes 
does not exceed a limit, or the window timing needs to be re-arranged. 

10.2.4.3.2 If more slaves have changed status, the command MC-FOT shall be used in order to save frame 
time. 

10.2.4.3.3 The limit between the use of MC-FOT and MC-FOT U is at the discretion of system administration. 

10.2.4.4 Effect on receipt 

10.2.4.4.1 On receipt of this command the slave whose start and/or stop index have changed uses a new 
window with a new start and stop time slot as indicated in the FOTU for subsequent communication. 

10.2.4.4.2 The receiving MAC shall enable the detection of a window synchronisation signal W-Sync in the 
appropriate time interval defined in the FOTU and shall interpret the following window as its private window, 
broadcast window or multicast window. 
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10.2.5 frame organisation table steady {MC-FOT S) 

10.2.5.1 Function 

This command is sent if the registration status of the slaves has not changed since the last frame, and the 
timing of windows is maintained. 

It shall be used in the MnlV only, 

10.2.5.2 Semantics of the service primitive 

MC-FOTS 

10.2.5.3 When generated 

This command is generated by the MAC in the event that, since the last frame, no slaves have changed from 
"registered" to "not registered" or vice versa. 

10.2.5.4 Effect on receipt 

The MAC receiving this command does not alter its window timing. 

10.2.6 Broadcast (MC-SRC) 

10.2.6.1 Function 

This command indicates that the following data stream is a broadcast message. 

Broadcast messages sent in the management window shall not be continued in another frame. They shall fit in 
the current management window. 

It shall be used in the /Wnl/Vonly. 

10.2.6.2 Semantics of the service primitive 

MC-BRC {broadcast length} 



Attribute 



Broadcast length 



Description 



One byte length of broadcast message in terms of transmitted 
12 bit units (8 bit Info plus 4 bit Hamming). 



10.2.6.3 When generated 

This command is generated by the MAC on request of the IR-CAL. 

This command shall be followed immediately by the data to be broadcast. 

10.2.6.4 Effect on receipt 

The broadcast data is fonwarded by the receiving MAC to the IR-CAL together with address information. 
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10.2.7 Re-establish session {MC-REST) 

10.2.7.1 Function 

With this command, a slave which lost and re-established the link, and thus now has a new TempID, may ask 
the master to re-establish all sessions related to its "old" TempID. 

It shall be used in a PrUV only 

10.2.7.2 Semantics of tlie service primitive 

MC-REST {MID. TempID} 

Table 16 — Session re-establishment 



Attribute 


Length 


Description 


MID 


3 byte 


MID of last master the slave has communicated with 


TempID 


2 byte 


last valid TempID 



10.2.7.3 When generated 

This command is generated by the IR-ME of the slave in the event that the communication link was lost for 
more than two times the maximum frame duration, arrd new registration was successful at the same master. 

10.2.7.4 Effect on receipt 

In the event that the master can accept the command, the IR-ME informs the CALM management about 
change of address. The master responds with the command "session re-establishment confirmed" 
{MC-RESQ. 

If the master cannot accept the command, it responds with the command "session re-establishment denied" 
{MC-RESD). 

10.2.8 Session re-establishment confirmed (MC-RESC) 

10.2.8.1 Function 

With this command, the master confimns the requested session re-establishment to the slave. 
It shall be used in a P/W only. 

10.2.8.2 Semantics of the service primitive 

MC-RESC 

10.2.8.3 When generated 

This command is generated by the l\/IAC of the master to confirm the re-establishment of the session. 

1 0:2.8.4 Effect on receipt 

IR-ME informs the CALM management about change of address. 
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10.2.9 Session re-establishment denied {MC-RESD) 

10.2.9.1 Function 

With this command, the master denies the requested session re-establishment to the slave. 
It shall occur in the PrW only. 

10.2.9.2 Semantics of the service primitive 
MC-RESD 

10.2.9.3 When generated 

This command is generated by the MAC of the master to deny the re-establishment of the sessions in the 
event that the session parameters are not available. 

10.2.9.4 Effect on receipt 

IR-ME informs the CALM management about loss of communication. 

10.Z.10 Kill all (MC'KIA) 

10.2.10.1 Function 

This command orders all slaves in the communication zone of the master to terminate atl registered 
communication with the master. 

It shall be used in the MrtWonly. 

If used, it shall occur before MC-FOT or MC-FOT U 

10.2.10.2 Semantics of the service primitive 

MC'KIA 

10.2.10.3 When generated 

This command is generated by the MAC on request of the IR-ME to temiinate communication. 

10.2.10.4 Effect on receipt 

On receipt of this command the MAC shall 

— inform the IR-ME about loss of communication, 

— cancel the association with the master, 

— delete pending frames, 

— invalidate the TemplD. 

The slave may enter a new registration process at any convenient time. 
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10.2.11 Kill slave (AfC-K/S) 

10.2.11.1 Function 

This command orders a dedicated slave in the communication zone of the master to terminate 
communications related to the specific TempID, i.e. to invalidate this TemplD. 

It shall be used in the MnWorAy. 

If used, it shall occur before MC-FOT or MC-FOT U. 

10.2.11.2 Semantics of the service primitive 

MC-KIS {TempID) 



Attribute 



TempID 



Description 



The identifier of the slave which has to be killed 



10.2.11.3 Wlien generated 

This command is generated by the MAC on request of the IR-ME to terminate communication. 

10.2.11.4 Effect on receipt 

On receipt of this command, the MAC shall 

— inform the IR-ME about loss of communication, 

— cancel the association with the master, 

— delete pending frames, 

— invalidate the TempID. 

The slave may enter a new registration process at any convenient time. 

10.2.12 De-reglster (MC-D/?£G) 

10.2.12.1 Function 

This command requires the peer entity to terminate the communication relation. 
It shall be used in the Prl/Vonly. 

10.2.12.2 Semantics of the service primitive 
MC-DREG { } 

10.2.12.3 When generated 

This command is generated by the MAC on request of the IR-ME to terminate communication relation and to 
avoid new registration within a defined time of Tq^^^q. 
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10.2.12.4 Effect on receipt 

10.2.12.4.1 On receipt of this command by the master, the MAC shall 

— inform the IR-ME about loss of communication, 

— delete the association with the slave, 

— delete all pending frames. 

10.2.12.4.2 On receipt of this command by the slave, the MAC shall 

— inform the IR-ME about loss of communication, 

— delete the TempID, 

— delete all pending frames. 

10.2.12.4.3 The slave may enter a new registration process at this master offered by the MAC command 
MC-REN only after a waiting time of Tq^^^q. 

10.2.12.4.4 The slave shall enter immediately a new registration process at this master offered by the MAC 
command MC-RRQ. 

10.2.13 Suspend ail (MC-SUA) 

10.2.13.1 Function 

10.2.13.1.1 This command orders all registered slaves in the communication zone of the master to suspend 
communications in their private windows and the related time-outs during this frame. 

it shall be used in the MnM/only. 

tf used, it shall occur before the MC-FOT or MC-FOT U is sent. 

10.2.13.1.2 In the event that a following MC-FOT, MC-FOT U or MC-FOT S command again allocates a PrW 
^or this TempID, this MC-FOT, MC-FOT U or MC-FOT S command overrides the suspend command. 

NOTE This command is used to i^eep ail staves "alive" although not being addressed in the current frame. The now 
unused "airtime" of the current frame can now be used, for example, for a broadcast window or by "non-CALM" masters, 
assuming they are synchronised appropriately with the "CALM master". See Annex E. 

10.2.13.2 Semantics of the service primitive 

MC'SUA 

10.2.13.3 When generated 

This command is generated by the MAC IR-ME itself dependent on the priority of pending transmission 
requests. 

10.2.13.4 Effect on receipt 

On receipt of this command, the MAC shall suspend any communications in private windows In the current 
frame and shall suspend related timer time-out in the current frame. 

in the event that a following MC-FOT, MC-FOT U or MC-FOT S command again allocates a slave a TempID, 
this MC-FOT, MC-FOT U or MC-FOT S command overrides the suspend command. 
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10.2.14 Suspend slave {MC-SUS) 

10.2.14.1 Function 

10.2.14.1.1 This command orders a specific slave in the communication zone of the master to suspend its 
communication in the private window related to the concerned TempID and related time-outs during this frame. 

It shall be used in the MnW and PaW only. 

If used in a MnW, it shall occur before the MC-FOTor MC-FOT U command is sent. 

10.2.14.1.2 In the event that a following MC-FOT, MC-FOT U or /WC-F07 S command again allocates a PrW 
for this TempID, this MC-FOT, MC-FOT U or MC-FOrs command overrides the suspend command. 

NOTE This command is issued by the master to a newly registering Siave in the event that in the current frame a 
window cannot be allocated instantly and a complete frame reorganisation is necessary. However, the slave is informed 
that its registration attempt was successful. 

10.2.14.2 Semantics of the service primitive 

MC-SUS {TempID} 



Attribute 



TempID 



Description 



2 byte TempID identifies the slave to be suspended 



10.2.14.3 When generated 

This command is issued by the master to a newly registering slave in the event that in the current frame a 
window cannot be allocated instantly and a complete frame reorganisation is necessary. 

10.2.14.4 Effect on receipt 

10.2.14.4.1 On receipt of this command, the MAC 

— shall suspend any communications in private windows in the current frame, 

— shall suspend related timer time-out in the current frame. 

10.2.14.4.2 In the event that a following MC-FOT, MC-FOT U or MC-FOT S command again allocates a slave 
a TempID, this MC-FOT, MC-FOT U or MC-FOT S command overrides the suspend command. 

10.2.15 Free airtime (MC-FAT) 

10.2.15.1 Function 

This command is used by the master to indicate the start of the free airtime in the event that "free airtime" is 
allocated before the start of the next frame. 

10.2.15.2 Semantics of the service primitive 

MC-FAT 
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10.2.15.3 When generated 

In the event that free air time is allocated, this command shall be sent after the last window, e.g. after the 
W-Sync indicating the end of the last window. 

10.2.15.4 Effect on receipt 

Slaves intending to become a sub-master use the free airtime to set up a frame, etc. 
10.3 MAC commands related to flow control 
10.3.1 Command not supported (MC-CNS) 

10.3.1.1 Function 

This command indicates that a command previously received in a PrWls not supported. 

This command implies the transfer of a token. 

The command shall be used in a private window only. 

10.3.1.2 Sernantics of the service primitive 

MC-CNS {CNSy 



Attribute 



CNS 



Description 



1 byte code of the command which is not supported. 



10.3.1.3 When generated 

The MAC sends this command at the earliest possible point in time after receipt of the unsupported command. 

10.3.1.4 Effect on receipt 

The IR-ME is informed that the peer entity does not support the command indicated. 
10.3.2 Tolten {MC-TKN) 

10.3.2.1 Function 

10.3.2.1.1 With this command, the sending device hands over the token to its communication partner in the 
event that there is nothing to be sent. The token indicates the right to transmit. 

The command shall be used in a private window only. 

10.3.2.1.2 An answer is expected within r^j. In the event of a time-out, the token falls back. 

10.3.2.2 Semantics of the service primitive 

MC-TKN 

10.3.2.3 When generated 

The MAC sends this command if no data or commands are to be transmitted at this point in time. 
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10.3.2.4 Effect on receipt 

The receiving MAC changes the device state from the receive state to the transmit state in order to continue 
communications: 

— in the event that the receiving MAC has data pending to be sent, the MAC sends this data; or 

— in the event that the receiving MAC has nothing to send, the MAC replies with MC-TKN. 

10.3.3 Block start (MC-BLS) 

10.3.3.1 Function 

With this command, the sending MAC indicates the start of transmission of a data block for CALM-fast 
applications. 

MC-BLS may be used in all windows except in a wake-up window or a spare window. 

10.3.3.2 Semantics of the service primitive 

MC-BLS {block number} 



Attribute 


Description 


Block number 


One byte number of new block 



10.3.3.3 When generated 

This command is sent by the MAC at the start of a data block for CALM-fast applications to be transmitted. 

10.3.3.4 Effect on receipt 

Open a new receive buffer for CALM-fast applications. 

NOTE The first packet in a block has always packet number OOH. 

10.3.4 Control channel block start (MC-CCBS) 

10.3.4.1 Function 

With this command, the sending MAC indicates the start of transmission of a control data block. This is 
equivalent to using the CALM control channel. 

MC-CCBS may be used in all windows except in a wake-up window or a spare window. 

10.3.4.2 Semantics of the service primitive 

MC-CCBS (block number} 



Attribute 


Description 


Block number 


One byte number of new block 
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10.3.4.3 When generated 

This command is sent by tiie MAC at the start of a data block in the control channel. 

10.3.4.4 Effect on receipt 

Open a new receive buffer for the CALM control channel. 
NOTE The first packet in a block has always packet number OOH. 

10.3.5 IEEE-frame block start {MC-FBS) 

10.3.5.1 Function 

With this command, the sending MAC indicates the start of transmission of a data block in the IEEE 802 
compliant mode. 

The command shall be used in a private window only. 

10.3.5.2 Semantics of the service primitive 

MC-FBS {block number} 



Attribute 


Description 


Block number 


One byte number of new block 



10.3.5.3 When generated 

This command is generated by the MAC in the event that an IEEE IPv6 frame has to be transmitted. 

10.3.5.4 Effect on receipt 

Open a new receive buffer for IEEE 802 compliant mode. 
NOTE The first packet in a block has always packet number OOH. 

10.3.6 Start of IV1AC control block (MC-SMC) 

10.3.6.1 Function 

With this command, the sending MAC indicates the start of transmission of a command block to be forwarded 
to the IR-ME of the receiving CALM device. 

The command shall be used in a private window only. 

1 0.3.6.2 Semantics of the service primitive 

MC-SMC {block number} 



Attribute 


Description 


Block number 


One byte number of new block 
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10.3.6.3 When generated 



This command is generated by the MAC on request of the IR-ME in the event that a manufacturer-dependent 
service application wants to "tunnel" information into the receiving MAC. 

10.3.6.4 Effect on receipt 

Open a new receive buffer for MAC control block. 

NOTE The first packet in a block has always packet number OOH 

10.3.7 Packet start (MC-PAS) 

10.3.7.1 Function 

With this command, the sending MAC indicates the start of a data packet. 

This data packet is the continuation of a transmission which did not completely fit in the previous packet. 

MC'PAS may be used in all windows except in a wake-up window or a spare window. 

10.3.7.2 Semantics of the service primitive 

MC-PAS {block number, packet number} 



Attribute 



Description 



Block number, packet number 



Number of block to which the packet belongs, number of actual packet 



10.3.7.3 When generated 

This command is sent by the MAC at the start of a data packet to be transmitted. 

10.3.7.4 Effect on receipt 

Add received data to the corresponding receive buffer. 
10.3.8 Packet end (MC-P/»E) 

10.3.8.1 Function 

With this command, the sending device indicates that a packet of data has been transmitted. Except in a BcW 
or an McW, the transmit token is given to the receiving device. 

The command implies that at least a further packet will follow. 

MC-PAE may be used in all windows except in a wake-up window or a spare window. 

1 0.3.8.2 Semantics of the service primitive 

MC-PAE 
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10.3.8.3 When generated 

This command is sent by the MAC of the sending device at the end of a transmitted data pacltet if another 
pacl<et of the same blocl< is pending. 

10.3.8.4 Effect on receipt 

According to the communication profile used, the receiving i\^AC performs error correction. 

— In the event of no or correctable errors, the MAC replies with MC-TAck or MC-TAck& and adds the 
received data to the corresponding receive buffer. 

— In the event of non-correctable errors, the MAC replies with MC-TNAck or MC-TNAckSi and discards the 
packet. 

10.3.9 Block end (MC-6L^ 

10.3.9.1 Function 

With this command, the sending device indicates that a packet of data has been transmitted and indicates the 
end of the block. Except in a BcW or an McW, the transmit token is given to the receiving device. 

IWC-SLE may be used in all windows except in a wake-up window. 

10.3.9.2 Semantics of the service primitive 

MC-BLE {block number} 



Attribute 



Btock number 



Description 



Number of block of which the last packet was sent at least once 



10.3.9.3 When generated 

This command is sent by the MAC of the sending device at the end of a transmitted information block. 

10.3.9.4 Effect on receipt 

According to the communication profile used, the receiving MAC performs error correction. 

— In the event of no or correctable errors, the MAC replies with MC-TAck or MC-TAck& and adds the 
received data to the corresponding receive buffer. 

— In the event of non-correctable errors, the MAC replies with MC-TNAck or MC-TNAck& and discards the 
packet. 

In the event of error-free reception of the packet, the completeness of the block is checked. If the block is 
complete, it is forwarded to the IR-CAL and successful reception of the block is acknowledged to the peer 
station with the MAC command MC-BAck. If packets are missing, retransmission of these packets is 
requested with the MAC command MC-RTQ. 

10.3.10 Transmission acknowledged {MC-TAck) 

10.3.10.1 Function 

With this command, the MAC confirms the error-free receipt of a data packet. 
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The command shall be used in a private window only. 
The communication token is given back. 

10.3.10.2 Semantics of the service primitive 
MC-TAck 

10.3.10.3 When generated 

In the event of a transmission received with no or corrected errors. 

10.3.10.4 Effect on receipt 

The last transmitted packet will be erased from the buffer. 
The communication token is recognised. 

10.3.11 Transmission acknowledged & {MC'TAck&) 

10.3.11.1 Function 

With this command, the MAC confirms the error-free receipt of a packet. 
The communication token is not given back. 
Additional information shall follow this command. 
The command shall be used in a private window only. 

10.3.11.2 Semantics of the service primitive 

MC-TAck& 

10.3.11.3 When generated 

In the event of a transmission received with no or corrected errors and information pending for transmission. 

10.3.11.4 Effect on receipt 

The last transmitted packet will be erased from the buffer. 

The receiving unit waits for the MAC command following the MC-TAck&. 

10.3.12 Transmission not acknowledged {MC-TNAck) 

10.3.12.1 Function 

With this command, the MAC confirms the erroneous receipt of a data packet. 

The communication token is given back. 

The command shall be used in a private window only. 
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10.3.12.2 Semantics of the service primitive 

MC-TNAck 

10.3.12.3 When generated 

In the event of a transmission received with uncorrectable errors. 

10.3.12.4 Effect on receipt 

The receiving device retransmits the last packet. 

10.3.13 Transmission not acknowledged & [MC'TNAckS.) 

10.3.13.1 Function 

With this command, the MAC confirms the erroneous receipt of a data packet. 
The communication token is not given back. 
Additional information shall follow this command. 
The command shall be used in a private window only. 

10.3.13.2 Semantics of the service primitive 
MC-TNAck& 

10.3.13.3 When generated 

In the event of a transmission received with uncorrectable errors and information pending for transmission. 

10.3.13.4 Effect on receipt 

The receiving unit waits for the MAC command following the MC-TNAck&. 

The receiving device retransmits the last packet at the earliest possible point in time. 

10.3.14 Retransmission request {MC-RTQ) 

10.3.14.1 Function 

If a non-correctable transmission error is detected by the MAC, this command requests the retransmission of 
the packet. 

The command shall be used in a private window only. 

10.3.14.2 Semantics of the service primitive 
MC-RTQ {block number, packet number} 



Attribute 



Block number 



Packet number 
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One byte number of the corrupted/missing packet. 
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10.3.14.3 When generated 



This command is generated by the MAC If a non-correctable transmission error is detected or a block is not 
complete at time of successful reception of the last packet of this block. 

10.3.14.4 Effect on receipt 

The receiving MAC repeats the requested packet. 
10.3.15 Block acknowledge {MC-BAck) 

10.3.15.1 Function 

This command acknowledges the successful, error-free reception of a complete block. 
The command shall be used in a private window only. 

10.3.15.2 Semantics of the service primitive 

MC-BAck {block number} 



Attribute 



Block number 



Description 



One byte number of block which is to be acknowledged. 



10.3.15.3 When generated 

Generated by the MAC after successful re-assembly of the received block. 

10.3.15.4 Effect on receipt 

Erase transmit block buffer. 
Release block number. 

10.4 MAC commands related to the registration process 

10.4.1 Registration enable (MC-/7E/V) 

10.4.1.1 Function 

This command indicates the start of a registration phase which enables all devices as selected by the attribute 
to participate. 

It shall be used in a MnW only. 

1 0.4.1 .2 Semantics of the service primitive 

MC-REN {Selector} 



Attribute 


Description 


Selector 


One byte: 

Selector bit = 0: Registration of the related group is disabled 
Selector bit = 1. Registration of the related group is enabled 
See also Table 17. 
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Table 17 — MC-REN group selector 



Selector bit 
number 


Related group 


(LSB) 


Group 0: Safety services (highest priority) 


1 


Group 1 : Governmental services 


2 


Group 2: Standard CALM-fast applications 


3 


Group 3: Standard internet services 


4 


Group 4: tbd 


5 


Group 5: tbd 


6 


Group 6: tbd 


7 (MSB) 


Group 7: tbd (lowest priority) 



10.4.1.3 When generated 

Generated by the MAC of the master in order to allow only devices of the indicated groups to enter the 
registration process. 

10.4.1.4 Effect on receipt 

Devices belonging to at least one of the enabled groups enter the registration process. 

10.4.2 Registration request {MC-RRQ) 

10.4.2.1 Function 

This command indicates the start of a registration phase which forces all devices as selected by the attribute 
to participate. 

It shall be used in a MnW only. 

10.4.2.2 Semantics of the sen/ice primitive 

MC-RRQ {Selector} 



Attribute 


Description 


Selector 


One byte: 




Selector bit = 0: Registration of the related group is disabled 




Selector bit = 1: Registration of the related group is enforced 




See also Table 1 7. 



10.4.2.3 When generated 

Generated by the MAC of the master in order to force devices of the indicated groups to enter the registration 
process. 

10.4.2.4 Effect on receipt 

Devices belonging to at least one of the indicated groups are forced to enter the registration process. 



48 



18 15754:2006 
ISO 21214: 2006 



10.4.3 Identifier request {MC-IDQ) 

10.4.3.1 Function 

With this command the slave proposes to the master a TemplD. 
The command shall be used in a MnW on\y. 

10.4.3.2 Semantics of the service primitive 

MC-IDQ {TemplD} 



Attribute 


Description 


TemplD 


The TemplD proposed by the slave. 



10.4.3.3 When generated 

This command is generated by the MAC of the slave. 

10.4.3.4 Effect Qn receipt 

In the event that the proposed TemplD Is not yet used by one of the slaves in the master's communication 
zone, the master confirms to the slave that the proposed TemplD can be used. 

In the event that the proposed TemplD is used by one of the slaves in the master's communication zone, the 
master gives no reply at all. 

In the event that the proposed TemplD is disturbed or faulty, the master gives no reply at all. 
10.4.4 Identifier response (MC'/DP) 

10.4.4.1 Function 

With this command, the master confirms to the slave that the proposed TemplD can be used. 
The command shall be used in a MnlVonly. 

10.4.4.2 Semantics of the service primitive 

MC-IDP {TemplD} 



Attribute 


Description 


TemplD 


The TemplD proposed by the slave. 



10.4.4.3 When generated 

In the event that the proposed TemplD is not yet used in the communication zone of the master, this 
command is sent as confirmation that the use of the proposed TemplD is granted. 
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10.4.4.4 Effect on receipt 

!n the event that the MAC recognises the proposed TempID, it reconfirms with the command registration 
confirmation and the IR-ME is informed about establishment of a new association with a master. 

in the event that TempID is not recognised as the one proposed, the slave enters the registration process 
again. 

10.4.5 Registration confirmation {MC-REC) 

10.4.5.1 Function 

The command registration confirmation is sent by the MAC of the slave if the master sends back the proposed 
TempID of the slave. 

The command shall be used in a MnW on\y. 

10.4.5.2 Semantics of the service primitive 

MC'REC 

10.4.5.3 When generated 

This command is generated by the MAC of the slave after receiving its proposed TempID from the master. 

1 0.4.5.4 Effect on receipt 

The proposed TempID of the slave is validated. 

The IR-ME is informed about establishment of a new association with a master. 

10.5 MAC commands related to the physical layer parameters 

10.5.1 Profiles request (AfC-P/?Q) 

10.5.1.1 Function 

This command requests the receiving device to submit the code of all communication profiles that the device 
is able to handle. 

The command shall be used in a private window only. 

10.5.1.2 Semantics of the service primitive 

MC-PRQ 

10.5.1.3 When generated 

This command is generated by the MAC on request of the IR-ME. 

10.5.1.4 Effect on receipt 

The receiving MAC forwards the request to the IR-ME. 
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10.5.2 Profiles response {MC-PRP) 

10.5.2.1 Function 

This command replies to tlie command MC-PRQ with a table containing ail the designators of the 
communication profiles that the responding device is able to use. 

The command shall be used in a private window only. 

10.5.2.2 Semantics of the service primitive 

MC-PRP {profile indicator} 



Attribute 


Description 


Profile indicator 


Two bytes. Meaning of bits as defined in Table 18. 



Table 18 — Profile indicators 



Bit position 


Profile 


Profile selector 


(LSB) 


Profile 





1 


Profile 1 


1 


2 


Profile 2 


2 


3 


Profile 3 


3 


4 


Profile 4 


4 


5 


Profile 5 


5 


6 


Profile 6 


6 


7 


Profile 7 (reserved for future use) 


7 


8 


Profile 8 (reserved for future use) 


8 


9 


Profile 9 (reserved for future use) 


9 


10 


Profile 10 (reserved for future use) 


10 


11 


Profile 1 1 (reserved for future use) 


11 


12 


Profile 12 (reserved for future use) 


12 


13 


Profile 13 (reserved for future use) 


13 


14 


Profile 14 (reserved for future use) 


14 


15(MSB) 


Extension indicator 


Not applicable 



If a bit position is set to "1", the related profile is indicated. 

If the MSB, i.e. the extension indicator, is set to "1", further profiles exist. This functionality is reserved. 

10.5.2.3 When generated 

This command is generated by the MAC on request of the IR-ME as response to an MC-PRQ. 
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10.5.2.4 Effect on receipt 

The receiving MAC forwards the profile designators to the IR-ME. 
10.5.3 Request new profile (MC-RNP) 

10.5.3.1 Function 

With this command, a slave requests the master to assign a new communications profile to the private window. 
The command shall be used in a private window only. 

10.5.3.2 Semantics of the service primitive 

MC-RNP {profile selector} 



Attribute 


Description 


Profile selector 


One byte indicating the requested profile (see Table 18). 



10.5.3.3 When generated 

This command is generated by the MAC on request of the IR-ME, when a change of profile is necessary, 

10.5.3.4 Effect on receipt 

The receiving MAC forwards the request to the IR-ME. 

The receiving device suspends all "non command" communications in the private window until a new 
communications profile is set. 

The IR-ME decides on acceptance or non-acceptance of this request. The underlying rules are outside the 
scope of this International Standard. 

In the event of acceptance, the IR-ME shall request the MAC to transmit MC-SPR with the requested profile 
designator as attribute. 

in the event of non-acceptance of any of the requested profiles, the IR-ME 

— shall request the MAC to transmit MC-SPR with the profile selector of the currently used profile as 
attribute in order to confinue with the current profile, if the requested new profile implies higher data rate 
than the actual one, or 

— shall request the MAC to transmit MC-SPR with the profile selector of the default profile in order to set the 
requestor to the default profile. 

10.5.4 Set profile (MC-SPR) 

10.5.4.1 Function 

With this command, the master sets the appropriate profile to communicate with the slave in its private 
window (PiW). 

The command shall be used in a private window only. 
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1 0.5.4.2 Semantics of the service primitive 

MC-SPR {profile selector} 



Attribute 


Description 


Profile selector 


One byte indicating the requested profile (see Table 18). 



10.5.4.3 When generated 

This command is generated by the l\/IAC of the master on request of the IR-ME. 

10.5.4.4 Effect on receipt 

The receiving MAC forwards the request to the IR-ME in order to adjust its own communications profile for this 
private window. 

The slave gets the token. 

The MC-SPR shall be confirmed with MC-SPC. 

10.5.5 Set profile confirmation (MC-SPC) 

10.5.5.1 Function 

This command confinns the successful activation of the profile as indicated with the command MC-SPR. 

10.5.5.2 Semantics 

MC-SPC 

10.5.5.3 When generated 

This command is generated by the MAC after successful activation of the profile. 

10.5.5.4 Effect on receipt 

The new profile becomes valid. 

The master gets the token. 

The IR-ME is informed about the new communication profile. 

10.5.6 Set multicast profile {MC-SMP) 

10.5.6.1 Function 

This command sets the communications profile which is to be used in the current multicast window. 
The command shall be used in a multicast window only. 
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10.5.6.2 Semantics 

MC-SMP {profile selector} 



Attribute 


Description 


Profile selector 


One byte Indicating the requested profile (see Table 18). 



10.5.6.3 When generated 

This command is generated by the MAC at the beginning of each multicast window. 

10.5.6.4 Effect on receipt 

The new profile becomes valid. 

10.6 MAC commands related to test and services 

10.6.1 Status request 1 (MC-SRQI) 

10.6.1.1 Function 

This command requests the transmission quality parameters of the communication partner. 
The command shall be used in a private window only. 

10.6.1.2 Semantics of the service primitive 

MC-SRQI {transmission quality parameters indicator} 



Attribute 


Description 


Transmission quality parameters indicator 


One byte Indicating the requested parameters (see Table 19). 



Table 19 — Transmission quality parameters 



Bit pqsition 


Status parameter 


Description 


(LSB) 


Bit_counter 


Total number of received information bits 


1 


Bit_uncorrected 


Number of uncorrected infomnation bits 


2 


Bit_corrected 


Number of corrected infomiation bits 


3 


Packet counter 


Total number of received information packets 


4 


Packet retransmission 


Number of received retransmitted information packets 


5 


Block counter 


Total number of received infomfiation blocks 


6 


Block retransmission 


Number of received retransmitted information blocks 


7 


reserved for future use 





If a bit-position is set to "1", the related status information is requested. 
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10.6.1.3 When generated 

This command is generated by the MAC on request of the IR-ME. 

10.6.1.4 Effect on receipt 

In the event of reception with none or correctable errors, the receiving MAC responds with MC-TAck and 
fonwards the request to the IR~ME. 

In the event of reception with uncorrectable errors, the receiving MAC responds with MC-TNAck. 
10.6.2 Status request 2 {MC-SRQ2) 

10.6.2.1 Function 

This command requests the radiation parameters from the communication partner. 
The command shall be used in a private window only. 

1 0.6.2.2 Semantics of the service primitive 

MC-SRQ2 {field parameters indicator} 



AUrlbute 


Description 


Field parameters indicator 


One byte with all bits indicating the requested parameters set to one 
(see Table 20) 



Table 20 — Field parameters 



Bit position 


Status parameter 


Description 


(LSB) 


receiver class 


sensitivity class of receiver 


1 


transmitter class 


power class of the transmitter 


2 


field strength 


measured field strength at receiver input 


3 


solar radiation 


measured solar brightness at receiver input 


4 


reserved for future use 




5 


reserved for future use 




6 


reserved for future use 




7 


reserved for future use 





If a bit position is set to "1", the related status information Is requested. 

10.6.2.3 When generated 

This command is generated by the MAC on request of the IR-ME. 

10.6.2.4 Effect on receipt 

In the event of reception with none or correctable errors, the receiving MAC responds with MC-TAck and 
fonvards the request to the IR-ME. 

In the event of reception with uncorrectable errors, the receiving MAC responds with MC-TNAck. 
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10.6.3 Status request 3 {MC-SRQ3) 

10.6.3.1 Function 

This command requests the environmental parameters from the communication partner. 
The command shall be used in a private window only. 

10.6.3.2 Semantics of the service primitive 

MC-SRQ3 (environmental parameters indicator} 



Attribute 


Description 


Environmental parameters 
indicator 


One byte with all bits indicating the requested parameters 
set to one (see Table 21) 





Table 21 — 


Environmental parameters 


Bit position 


Status parameter 


Description 


(LSB) 


temperature 


ambient temperature 


1 


voltage 


battery voltage 


2 


battery charge 


remaining battery charge 


3 


reserved for future use 




4 


reserved for future use 




5 


reserved for future use 




6 


resen/ed for future use 




7 


reserved for future use 





If a bit position is set to "1", the related status information is requested. 

10.6.3.3 When generated 

This command is generated by the MAC on request of the IR-ME. 

10.6.3.4 Effect on receipt 

In the event of reception with none or correctable errors, the receiving MAC responds with MC-TAck and 
forwards the request to the IR-ME. 

In the event of reception with uncorrectable errors, the receiving MAC responds with MC-TNAck. 
10.6.4 Status request 4 (MC-5/7Q4) 

10.6.4.1 Function 

This command requests the manufacturer and certification parameters from the communication partner. 
The command shall be used in a private window only. 
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10.6.4.2 Semantics of the service primitive 

MC-SRQ4 {manufacturer and certification parameters indicator} 



Attribute 


Description 


Manufacturer and certification 
parameters indicator 


One byte with all bits indicating the requested 
parameters set to one (see Table 22). 



Table 22 — IVIanufacturer and certification parameters 



Bit position 


Status parameter 


(LSB) 


Manufacturer ID 


1 


Serial number 


2 


Certification 1 


3 


Cei1ification2 


4 


Certifications 


5 


Certification4 


6 


reserved for future use 


7 


reserved <for future use 



If a bit position is set to "1", the related status information is requested. 

10.6.4.3 When generated 

This command is generated by the MAC on request of the IR-ME. 

10.6A4 Effect on receipt 

In the event of reception with none or correctable errors, the receiving MAC responds with MC-TAck and 
fonwards the request to the IR-ME. 

In the event of reception with uncorrectable errors, the receiving MAC responds with MC-TNAck. 
10.6.5 Status response 1 (MC-SR1) 

10.6.5.1 Function 

This command responds the requested transmission quality parameters to the communication partner. 
The command shall be used in a private window only. 

10.6.5.2 Semantics of the service primitive 

MC-SR1 {transmission quality parameters indicator} 



Attribute 


Description 


Transmission quality parameters indicator 


One byte indicating the available parameters (see Table 19). 
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The command shall be immediately followed by a table containing the requested status information. The 
status information is transmitted, starting with the least significant entry. 

Table 23 — Transmission quality parameters report 



Parameter 


Description 


Format 


Parameterl 


Bit_counter 


4 byte counter, LSB first 


Parameter2 


Bit_uncorrected 


4 byte counter, LSB first 


Parameters 


Bit_corrected 


4 byte counter, LSB first 


Parameter4 


Packet counter 


4 byte counter, LSB first 


Parameters 


Packet retransmission 


4 byte counter, LSB first 


Parameters 


Block counter 


4 byte counter, LSB first 


Parameter? 


Block retransmission 


4 byte counter, LSB first 


Parameters 


reserved for future use 


4 bytes 



The table is sent using the negotiated communications profile of the private window. The table is neither led 
nor trailed by any block or packet command. 

10.6.5.3 When generated 

This command is sent by the MAC on request of the IR-ME. 

10.6.5.4 Effect on receipt 

In the event of reception with none or correctable errors, the receiving MAC responds with MC-TAck and 
forwards the table to the IR-ME. 

In the event of reception with uncorrectable errors, the receiving MAC responds with MC-TNAck. 
10.6.6 Status response 2 {MC-SR2) 

10.6.6.1 Function 

This command responds the requested field parameters to the communication partner. 
The command shall be used in a private window only. 

10.6.6.2 Semantics of the service primitive 

MC-SR2 {field parameters indicator} 



Attribute 


Description 


Field parameters indicator 


One byte indicating the available parameter (see Table 24). 



The command shall be immediately followed by a table containing the requested status information. The 
status information is transmitted, starting with the least significant entry. 
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Table 24 — Field parameters report 



Parameter 


Description 


Format 


Parameterl 


receiver class 


one byte 


Parameter2 


transmitter class 


one byte 


Parameters 


field strength 


two bytes 


Parameter4 


solar radiation 


two bytes 


Parameters 


reserved for future use 


two bytes 


Parameters 


reserved for future use 


two bytes 


Parameter? 


reserved for future use 


two bytes 


Parameters 


reserved for future use 


two bytes 



The table is sent using the negotiated communications profile of the private window. The table is neither led 
nor trailed by any block or packet command. 

10.6.6.3 When generated 

This command is sent by the MAC on request of the IR-ME. 

10.6.6.4 Effect on receipt 

In the event of reception with none or correctable errors, the receiving MAC responds with MC-TAck and 
forwards the table to the IR-ME. 

In the event of reception with uncorrectable errors, the receiving MAC responds with MC-TNAck. 
10.6.7 Status response 3 {MC-SR3) 

10.6.7.1 Function 

This command responds the requested environmental parameters to the communication partner. 
The command shall be used in a private window only. 

10.6.7.2 Semantics of the service primitive 

MC-SR3 {environmental parameters indicator} 



Attribute 


Description 


Environmental parameters indicator 


One byte indicating the available parameters (see Table 25). 



The command shall be immediately followed by a table containing the requested status information. The 
status information is transmitted, starting with the least significant entry. 
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Table 25 — Environmental parameters report 



Parameter 


Description 


Format 


Parameterl 


Temperature 


one byte 


Parameter2 


Voltage 


one byte 


Parameters 


Battery charge 


one byte 


Parameter4 


reserved for future use 


one byte 


Parameters 


reserved for future use 


two bytes 


Parameters 


reserved for future use 


two bytes 


Parameter? 


reserved for future use 


two bytes 


Parameters 


reserved for future use 


two bytes 



The table is sent using the negotiated communications profile of the private window. The table is neither led 
nor trailed by any block or pacl<et command. 

10.6.7.3 When generated 

This command is sent by the MAC on request of the IR-ME. 

10.6.7.4 Effect on receipt 

In the event of reception with none or correctable errors, the receiving MAC responds with MC-TAck and 
forwards the table to the IR-ME. 

In the event of reception with uncorrectable errors, the receiving MAC responds with MC-TNAck. 
10.6.8 Status response 4 {MC-SR4) 

10.6.8.1 Function 

This command responds the requested manufacturer and certification parameters to the communication 
partner. 

The command shall be used in a private window only. 

1 0.6.8.2 Semantics of the service primitive 

MC-SR4 {manufacturer and certification parameters indicator} 



Attribute 


Description 


Manufacturer and certification parameters 
indicator 


One byte indicating the available parameters (see Table 26) 



The command shall be immediately followed by a table containing the requested status information. The 
status information is transmitted, starting with the least significant entry. 



60 



IS 15754 : 2006 
ISO 21214: 2006 



Table 26 — Manufacturer and certification parameters report 


Parameter 


Description 


Format 


Parameterl 


Manufacturer ID 


4 bytes, LSB first 


Parameter2 


Serial number 


4 bytes, LSB first 


Parameters 


Certification 1 


4 bytes, LSB first 


Parameter4 


Certification2 


4 bytes, LSB first 


Parameters 


Certifications 


4 bytes, LSB first 


Parameters 


Certification4 


4 bytes, LSB first 


Parameter? 


reserved for future use 


4 bytes, LSB first 


Parameters 


reserved for future use 


4 bytes, LSB first 



The table is sent using the negotiated communications profile of the private window. The table is neither led 
nor trailed by any block or packet command. 

10.6.8.3 When generated 

This command is sent by the MAC on request of the IR-ME. 

10.6.8.4 Effect on receipt 

In the event of reception with none or correctable errors, the receiving MAC responds with MC-TAck and 
forwards the table to the IR-ME. 

In the event of reception with uncorrectable errors, the receiving MAC responds with MC-TNAck. 
10.6.9 Echo alert (AfC-£4) 

10.6.9.1 Function 

This command requests the MAC of the recipient to prepare for answering the echo request with a predefined 
delay time in order to enable the requestor to calculate the signal travelling time or distance between the two 
communication partners by considering the delay time. 

MC-EA shall be followed by no other command than MC-ERQ. 

MC-EA is only valid for the current window. 

The command shall be used in a private window only. 

10.6.9.2 Semantics of the service primitive 

MC-EA {} 

10.6.9.3 When generated 

This command is generated on request of the service application via the IR-ME. 
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10.6.9.4 Effect on receipt 

In the event of reception with none or correctable errors, the receiving MAC prepares for a response to an 
MC-ERQ with a defined delay time. 

In the event of reception with uncorrectable errors, the receiving MAC responds with MC-TNAck. 

10.6.10 Echo request {MC-ERQ) 

10.6.10.1 Function 

This command requests the MAC of the recipient to respond after the delay time T^q with the command echo 
(MC-EChf) in order to enable the requestor to calculate the signal travelling time or distance between the two 
communication partners. 

The command shall be used in a private window only. , 

10.6.10.2 Semantics of the service primitive 

MC-ERQ { } 

10.6.10.3 When generated 

This command is generated by the MAC on request of the IR-ME after sending the command MC-EA. 

The command shall be preceded by the command MC-EA in the current window. 

After sending the command, the sending MAC shall change to the receive state and wait for a reply. 

10.6.10.4 Effect on receipt 

In the event of reception with none or correctable errors, the receiving MAC changes immediately into the 
"send state" and responds with the command "echo" after the delay T^q in the current window. 

in the event of reception with uncorrectable errors, the receiving MAC responds with MC-TNAck. 

10.6.11 Echo {MC-ECH) 

10.6.11.1 Function 

This command is sent by the MAC as reply to the command MC-ERQ. 
The command shall be used in a private window only. 

10.6.11.2 Semantics of the service primitive 
MC-ECH {echo delay time} 



Attribute 



Description 



Echo delay time 



2 byte giving the implementation-dependent, device internal delay time in nanoseconds 
between the reception of the first bit of the received command MC-ERQ and the first bit 
of the command MC-ECH. 
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10.6.11.3 When generated 

This command is generated by the IVIAC as reply to MC-ERQ. 

10.6.11.4 Effect on receipt 

In the event of reception with none or correctable errors, the receiving MAC forwards "echo delay time" to the 
IR-MElo be considered when calculating the signal travelling time or distance. 

In the event of reception with uncorrectable errors, the receiving MAC responds with MC-TNAck. 
10.7 MAC command set overview 

Table 27 — List of MAC commands 



Command 
code 


MAC command 


Mnemonic 


Length of 

attribute 

(bytes) 


Used in 

window 

types 


Initiated by 


Commands related to the frame and window organisation | 


82h 


frame organisation table 


/WC-F0r{F07 length} 


2 


MnW 


MAC 


83h 


frame organisation table update 


MCF0TU{F01V 
length} 


2 


MnW 


MAC 


04h 


frame organisation table-steady 


MC-FOTS{) 


none 


MnW 


MAC 


43h 


Broadcast 


MC-BRC {broadcast 
length} 


1 


MnW 


MAC 


COh 


Re-establish session 


MC-REST{MID, 
TempID} 


5 


PrW 


IR-ME 


OCh 


Session re-establishment confirmed 


MC-RESC{} 


none 


PrW 


IR-ME 


ODh 


Session re-establishment denied 


MC-RESD{} 


none 


PrW 


IR-ME 


06h 


Kill all 


MC-KIAO 


none 


MnW 


IR-ME 


86h 


Kill slave 


MC-KIS {TempID} 


2 


MnW 


IR-ME 


Olh 


Deregister 


MC-DREG { } 


none 


PrW 


IR-ME 


OFh 


Suspend all 


MC-SUA{} 


none 


MnW 


MAC 


8Ah 


Suspend slave 


MC-SUS {TempID) 


2 


MnW 


MAC 


05h 


Free airtime 


MC'FAT{} 


none 


MnW 


IR-ME 
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Table 27 (continued) 



Command 
code 


MAC command 


Mnemonic 


Length of 

attribute 

(bytes) 


Used in 

window 

types 


Initiated by 


Commands related to flow control | 


44h 


Command not supported 


MC-CNS{CNS\ 


1 


PrW 


MAC 


10h 


Token 


MC-TKN{} 


none 


PrW 


MAC 


42h 


Block start 


MC-BLS {block 
number} 


1 


PrW. McW, 
BcW, MnW 


IR-CAL 


45h 


Control channel block start 


MC-CCBS {block 
number} 


1 


PfW, BcW, 
McW 


IR-CAL 


46h 


IEEE-frame block start 


MC-FBS {block 
number} 


1 


PrW, BcW, 
McW 


IR-CAL 


4Ch 


Start of MAC control block 


MC-SMC {block 
number} 


1 


PrW. McW. 
BcW, MnW 


IR-ME 


87h 


Packet start 


MC-PAS {block 

number, packet 

number} 


2 


PrW. McW. 
BcW 


MAC 


07h 


Packet end 


MC-PAEU 


none 


PrW. McW. 
BcW 


MAC 


41h 


Block end 


MC-BLE {block 
number} 


1 


PrW, McW. 
BcW, MnW 


MAC 


11h 


Transmission acknowledged 


MC-TAck {} 


none 


PrW 


MAC 


12h 


Transmission acknowledged & 


MC-TAck& {} 


none 


PrW 


MAC 


13h 


Transmission not acknowledged 


MC'TNAck {} 


none 


PrW 


MAC 


14h 


Transmission not acknowledged & 


MC-TNAckS, {} 


none 


PrW 


MAC 


89h 


Retransmission request 


MC-RTQ {block 

number, packet 

number} 


2 


PrW 


MAC 


40h 


Block acknowledge 


MC-e^c/r {block 
number} 


1 


PrW 


MAC 


Commands related to the registration process | 


47h 


Registration enable 


MC-REN {Selector} 


1 


MnW 


MAC 


48h 


Registration request 


MC-RRQ {Selector} 


1 


MnW 


MAC 


84h 


Identifier request 


MC-IDQ {TempID) 


2 


MnW 


MAC 


85h 


Identifier response 


MC-IDP{TemplD) 


2 


MnW 


MAC 


OBh 


Registration confirmation 


MC-REC{} 


none 


MnW 


MAC 


Commands related to the physical layer parameters 


OAh 


Profiles request 


MC-PRQU 


none 


PrW 


IR-ME 


88h 


Profiles response 


MC-PRP {profile 
indicator} 


2 


PrW 


IR-ME 


49h 


Request new profile 


MC-RA/P {profile 
selector} 


1 


PrW 


IR-ME 


8Ch 


Set profile 


MC-SPR {profile 
selector} 


1 


PrW 


IR-ME 


OEh 


Set profile confirmation 


MC-SPC{} 


none 


PrW 


IR-ME 


4Ah 


Set multicast profile 


MC-S/WP {profile 
selector} 


1 


McW 


MAC 
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Table 27 {continued) 



Command 
code 


lUIAC command 


IVInemonIc 


Length of 

attribute 

(bytes) 


Used in 

window 

types 


initiated by 


Commands reiated to test and services | 


4Dh 


Status request 1 


MC-SRQ1 
{transmission quality 
parameters indicator} 


1 


PrW 


IR-ME 


4Eh 


Status request 2 


WC-SRQ2 {field 
parameters indicator} 


1 


PrW 


IR-ME 


4Fh 


Status request 3 


MC-SRQ3 

{environmental 

parameters indicator} 


1 


PrW 


IR-ME 


50h 


Status request 4 


MC-SRQ4 

{manufacturer and 

certification parameters 

indicator} 


1 


PrW 


IR-ME 


51 h 


Status response 1 


MC-SR1 {transmission 

quality parameters 

indicator} 


1 


PrW 


IR-ME 


52h 


Status response 2 


MC-SR2 {field 
parameters indicator} 


1 


PrW 


IR-ME 


53h 


Status response 3 


MC-SR3 

{environmental 

parameters indicator} 


1 


PrW 


IR-ME 


54h 


Status response 4 


MC-SR4 {manufacturer 

and certification 
parameters indicator} 


1 


PrW 


IR-ME 


02h 


Echo alert 


MC-EA{) 


none 


PrW 


IR-ME 


03h 


Echo request 


MC-ERQ{} 


none 


PrW 


MAC 


81h 


Echo 


MC-ECH {echo delay 
time} 


2 


PrW 


MAC 
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11 Registration procedure 

11.1 General 

11.1.1 The registration procedure enables newly entered devices to be registered for communication. During 
this process the slave is assigned a temporary identification (TempID), which is used for further addressing 
the slave device as long as it resides in the communication zone of the master. 

11.1.2 The registration procedure takes place in the registration phase of the management window (e.g. after 
the generic frame information MID. MID and FATI is sent). 

11.1.3 During the registration procedure, a slave which has newly entered the communication zone of a 
master and which has detected the F-Sync signal, the generic frame information and a MAC command 
registration enable or registration request which fits its priority creates a TempID with which it enters the 
registration process. 

11.2 Normal registration procedure 

11.2.1 The temporary identifier (TempID) is produced by the slave and proposed to the master to use it for 
further addressing of the slave. 

11.2.2 The proposed TempID is checked by the master for uniqueness in its communication zone and 
confirmed to the slave in case of a successful registration. 

11.2.3 A confirmed TempID is valid as long as the TempID time-out has not been exceeded. 

11.2.4 When producing a TempID proposal, the slave shall fulfil the requirements given in 11.2.4.1 to 
11.2.4.5, 

11.2.4.1 The TempID shall be a 2 byte random number. 

11.2.4.2 The slave shall not use one of the predefined reserved TemplDs (see Table 28). 

11.2.4.3 The slave device shall produce the TempID on a random basis such that all possible values are 
chosen with equal probability. 

11.2.4.4 In the event that a "pseudo-random" process is used, the sequence of random numbers shall not 
be identical in all slave units. 

11.2.4.5 The slave shall use a new random number for each registration process and for each registration 
attempt. 

1 1 .2.5 TempID codes are provided in Table 28. 

Table 28 — TempID codes 



ID number 


Name 


Description 


OOOOh 


Dummy-ID 


Identifier of the last entry ("dummy entry") in the FOT 


0001 h 


WuW-ID 


Identifier for wake-up window 


0002h..,.000Fh 


SpW-ID 


Identifiers for spare windows 


0010h...00FFh 


Future-ID 


Reserved for future use 


0100h...EFFFh 


Temp-ID 


Range of valid temporary identifiers 


FFOO...FFFEh 


multicast ID 


Range of valid multicast identifiers 


FFFFh 


Broadcast 


Broadcast identifier 



66 



18 15754:2006 
180 21214:2006 



11.3 Sequence of the registration procedure without collision 



11.3.1 The registration procedure is initiated with the command registration request {MC-RRQ) or registration 
enable (/WC-RE/V). 

11.3.2 After the sending of MC-RRQ or MC-REN, the master switches to the receive state and waits for an 
answer for a period of time T'rwait- 

11.3.3 An incoming device (slave), entering the communication zone, receives the command. 

11.3.4 After a random time delay Trec which may depend on the priority of the device and the number of 
any already failed registration attempts, the slave replies with the MAC command "identifier request" 
{MC-IDQ), whereby the attribute is the proposed TempID of the slave. 

11.3.5 If no other slave uses this TempID, the master answers with the MAC command MC-IDP with the 
TempID proposed by the slave as attribute. 

11.3.6 If the master detects that the TempID proposed by the slave is already used by some other slave, the 
master rejects the current registration procedure by sending a new registration command {MC-REN or 
/WC-RRQ). 

11.3.7 Other slaves receiving the TempID (via the master) not originated by themselves stay inactive until 
the next registration command. 

11.3.8 The slave recognising its proposed TempID confirms immediately by sending the MAC command 
"registration confirmation" (MC-REC). The TempID becomes active and will be considered by the master 
when creating a new FOT or FOTU. 

11.3.9 if the size of the management window allows it, the master may now broadcast a new registration 
command. 



RSU 


F-Sync 


MIO 


\FLen\FATi\ CA |RRQ|S8lecl| 




^ 


04 |/D0| TampiDJ 


k 


, / 


\CA 


\rrq\ 








\ 


r 

blocked 


¥ 




0BU_1 


Timeij CA 


IDQ 1 TemplO_ 1 1 


V 


\rbc 




0BU_2 




Timer 
















1 Registration Procedure [REC) 














Window 


MnW 



Figure 13 — Registration procedure without collision 

11.4 Sequence of the registration procedure with collision 

If two slaves reply simultaneously or overlapping with their proposed TempID, a collision occurs. 

There are three possible scenarios. 

11.4.1 Both signals appear with equal signal strength 

Two slaves reply simultaneously or overlapping with different TemplDs and both signals appear with equal 
signal strength at the master (e.g. from the same distance to the master). 

11.4.1.1 The master will receive a "wired OR" of both signals. 

11.4.1.2 If the received signal conforms to an "allowed" TempID, the master replies with MC-IDP with this 
"mixture" as attribute; otherwise, the master broadcasts another MC-RRQ or MC-REN. 
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11.4.1.3 As neither of the slaves receives its correct TempID, neither of them is addressed and thus 
neither of them confirms and no TempID becomes valid. 

11.4.1.4 The master thus gets no confirmation, and after a time-out period 7rj the master broadcasts 
again a registration command. 
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Figure 14 — Registration procedure with collision 

1 1 .4.2 Both signals appear with different signal strength 

Two slaves reply simultaneously with different proposed TemplDs, but both signals appear with different 
signal strength at the master (e.g. one slave is positioned nearby and the other far away from the master). 

1 1.4.2.1 The master will receive the "stronger" TempID. 

1 1 .4.2.2 The master replies with MC-IDP with this TempID as attribute. 

11.4.2.3 One slave receives its correct TempID and confirms, the other slave recognises that it is not 
addressed. 

11.4.3 Identical TemplDs 

Two slaves reply simultaneously with identical TemplDs. This is the only complicated situation, but this case 
happens very seldom. However, as described below, such a conflict will be detected, so countermeasures can 
be initiated on the upper layers, 

11.4.3.1 The master will receive a "correct" TempID. 

11.4.3.2 The master replies to this TempID. 

11 .4.3.3 Both slaves are addressed correctly and will be considered by the master as a single slave. 

11.4.3.4 Both slaves will be assigned to the same private window. 

11.4.3.5 This will cause collisions later on in the associated private window. As collisions can occur also 
for other reasons (e.g. cross-talking, interference), collisions in general shall be detected and solved by the 
layer 2 and above mechanism. 

11.4.3.6 If a collision in the same window occurs more than once, the slave(s) shall be "killed" by a MAC 
command in the management window. The result is that that the siave(s) will enter a new registration process. 

11,5 Handover and re-registration 

If a slave fails to respond in its private window in two consecutive frames, 11.5.1 and 11.5.2 apply. 
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11.5.1 Cancel TempID 



The master shall cancel the TempID from the FOT but shall store, for a predefined time interval, the various 
session data related to this slave in order to enable a re-establishment of sessions, etc. in case the slave 
enters a new registration process, gets a new TempID and has requested session re-establishment using the 
MAC command "re-establish session" (MC-REST). 

11.5.2 Advise adjacent masters 

The master shall advise the adjacent masters about which slave it "lost" in its communication zone {TempID, 
session status) in order to enable the slave to re-establish the session when reaching the communication 
zone of the next master ("handover"). 

11.6 Registration process timers 

Registration process timers are provided in Table 29. 

Table 29 — Registration process timers 



Timer 


Description 


Value 


^RWAIT 


The master shall wait at least 
^RWAiT ^°'' 3 '■®P'y ^0 9" ^C- 
RRQ or MC-REN. The 
reception of a reply shall be 
processed by the master as 
soon as possible, depending 
on the implementation 


7'rwait=125ms 


^REG 


Delay time before slave 
replies to an MC-RRQ or MC- 
REN 


Random 

^REG.min = 5 PS 
-^RECmax =^ ^^ MS 


'CWAIT 


Waiting time of the slave for a 
reply to a proposed TempID 


^CWAIT.max == ^2 |JS 


7'rT 


Waiting time of the master for 
a reply to its MC-IDP 


^RT,max = 25MS 


^TempID 


TempID time-out. 


255 

Measured in number of 

consecutive frames. 

Frames, in which the related 

slave was suspended, are 

not counted. 


^DREG 


Registration time-out 


60s 
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12 Window management 

12.1 General 

A TDMA frame includes, after the management window {MnW), a series of clustered time slots, wtiich form 
private and multicast windows {PrW, McW), enabling all the communication partners (master and slaves) to 
exchange information (e.g. application data and commands). 

Those windows have to be managed by the master in order to 

— allocate sufficient communication time to each slave device; 

— meet time requirements for critical applications (e.g. real-time applications); 

— maintain required command response/reaction time; 

— re-arrange the time slot allocation (if necessary). 

12.2 Window allocation by frame organisation tables 

Windows are created by allocating them a start and a stop index defining their start and stop position in the 
time structure of a frame. 

This organisation is transmitted to the slaves by the master during the management window using either of the 
MAC commands "frame organisation tabie" {MC-FOT) or "frame organisation table update" (MC-FOT U) that 
are defined in 10.2,1 and 10.2.4. 

Each window is addressed by a hexadecimal index of its time siot(s) from COH to FFH. The start time slot 
(time slot OOH) is the very first time slot after the F-Sync. 

If a slave is assigned to a window, this stays valid also for the next frame(s) until a new window is assigned or 
the communication ends. 

As all devices in the communication zone receive this FOT information, this organises the slaves without the 
need for "continuous window counting". Instead of many interrupts, one timer is set in the slave, unblocking 
the interrupt just before the start of the desired window. 

NOTE If no changes occur in the FOT, the command "frame organisation table steady" (MC-FOT S) is sent instead 

of the MC-FOT or MC-FOT U. 

The length of the window is the time difference from the start index to the start index of the subsequent 
window. The Dummy-ID is added to give the end information for the last window. 

This frame organisation method also avoids problems with "shadowing" which otherwise could lead to a 
temporal loss of sync, information. 

12.3 Spare windows 

In order to enable the master during the registration process to instantly assign a private window to a newly 
registering slave, the master may maintain a "spare window" by allocating, in the FOT, a reserved TempID to 
an otherwise unused window. 

If a slave newly registers, the master can assign the slave immediately this "spare window" by altering the 
"spare" TempID in the FOT before sending the FOT. 

The new slave thus has a private window for his disposition even in the frame he used for registering. 
A complete frame reorganisation (deleting or adding windows) then can be achieved before issuing a new 
frame. 
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12.4 Windows for isochronous services 



If a service has stringent requirements concerning jitter and (minimum) bandwidth, the windows allocated to 
slaves requiring such services shall 

— be as equidistant as possible; 

— have a minimum length in terms of information bits (not necessarily in time as the necessary window time 
depends on the data rate of the communications profile used in the window). 

Both criteria can be met by using a constant frame repetition rate (instead of using a constant inter-frame 
time) and placing the subject windows always in the same time slot. 

In the event that "gaps" occur because of time slots not allocated to any active slave, those gaps shall be filled 
with "spare windows" as described in 12.3. 



71 



15 15754:2006 
180 21214:2006 

13 Infra-red management entity 

13.1 General 

The infra-red management entity IR-ME is in charge of controlling the IR MAC layer and IR physical layer, i.e. 
in all issues where an interaction with the upper layers of the CALM management is necessary. 

13.2 MAC command not supported 

Normally, proper implementations never generate MAC commands not supported at peer stations, except 
where these commands are optional commands. 

Non-detectable transmission errors may lead to a not supported command. Thus reception of the MAC 
command MC-CNS shall enforce retransmission of the related MAC command. If this is not possible, or if the 
command not supported was sent out, then the link shall be closed using the MAC commands MC-DREG and 
MC-KIS, as applicable. 

13.3 Communication profiles 

The management of communication profiles is detailed in 10.5. Available profiles shall be reported to the 
Upper layers of the CALM management via the IR-MAE after power on and after every change of status. 

13.4 Equipment status 

The IR-ME shall maintain actual status information as described in the context of the MAC commands 

MC-SRQi and MC-SRi, / == 1 4, (see 10.6). These parameters shall be retrievable by the CALM 

management via the IR-MAE. 

13.5 Testing 

The IR-ME shall support tests as described in 10.6 on request of a service application via the CALM 
management and the IR-MAE. 

13.6 Registration 

The registration procedure is specified in detail in Clause 1 1 . 

A physical IR, identified by its MAC address which is unique in the CALM context, shall be able to maintain 
logical instances of an IR unit, each identified by a temporary MAC address. 

The unique MAC address is a six byte number as detailed in Figure 15. 



LS-Byte 


Bytel 


Byte 2 


Bytes 


Byte 4 


MS-Byte 


Vendor value, manufacturer identifier 


User value, serial number 


Individual, local 


Qualifier 


Identifier 



Figure 15 — Unique iVIAC address 

A MAC address consists of six bytes, divided into two groups: 

— vendor value (also referred to as manufacturer identifier); 

— user value (being a serial number). 
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If the "vendor" value indicates an individual local MAC address, the "user" value shall be the concatenation of 
a qualifier and an identifier. 



The MAC address qualifier shall be set as indicated in Figure 16. 



Comment 


LSB 


Bit1 


Bit 2 


Bit 3 


Bit 4 


Bits 


Bite 


MSB 


Unique MAC address for stationary 
equipment 


1 


1 


Extension of identifier, i.e. the identifier consists of 
22 bits. 


Unique MAC address for mobile 
equipment 





1 


Extension of identifier, i.e. the identifier consists of 
22 bits. 


Temporary MAC address for 
master 


1 





CCia 


F1 b 


Fob 


Sb 


Res.c 


Res. 


Temporary MAC address for slave 








CCl 


Res. 


Instance number '^ 



^ CCl is the control channel indicator. If set to "1", the logical unit constitutes a control channel. 

b FO, F1, and S are elements of the class identity code, see Table 12. 

^ Res. indicates a reserved bit which shall be set to "1". 

^ The instance number indicates the logical instance of an IR communication entity. 

Figure 16 — MAC address qualifier 

Any change of status for instances of IR communication units, i.e. any change in available MAC addresses, 
shall be reported to the CALM management via the IR-MAE, together with the related unique and temporary 
MAC address. 

13.7 Session management 

13.7.1 The management of sessions is specified in detail in 10.2, see MAC commands MC-REST, 
MC~RESC, MC-RESD, MC-SUA, MC-SUS, MC-DREG, MC-KIS, MC-KIA. 

13.7.2 A session, i.e. the association between an IR master and an IR slave given by the pair of MID and 
TempID, can be closed by either the master or the slave. 

13.7.2.1 The master may close the link by sending the MAC command MC-KIS {TempID}. 

13.7.2.2 The slave may request to close the link by sending the MAC command MC-DREG. 

13.7.2.3 In addition to this, the master can close all links by sending the MAC command MC-KIA. 

13.7.3 A slave may be prohibited from using airtime in a single specific frame without losing its association 
with the master by using the MAC commands MC-SUA, MC-SUS {TempID}. 

13.8 Communication 

13.8.1 Organisation of IR communication 

IR communication is organised in sequences of packets to be transmitted. Several packets may be associated 
with each other in an ordered sequence and buitd up a block, i.e. large blocks received from the IR-CAL need 
to be fragmented for transmission and defragmented after reception, (see 14.2.5). For details on MAC 
commands see 10.3. 
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13.8.2 Unique block number reference 

13.8.2.1 Every block shall be referenced by a unique block number In the range OOh to FFh. There shall be 
only a single block counter for all links of all logical instances of a single physical instance of an IR unit. 
A maximum of 256 blocks may be in use simultaneously. 

13.8.2.2 The packets in a block shall be sequentially numbered starting with OOh. 

13.8.2.3 The start of the first packet in a new block shall be indicated by one of the following block start 
commands: 

— MC-BLS {block number}: CALM-fast application data transmission; 

— MC-SCB {block number}: CALM-fast application control channel transmission; 

— MC-BRC {block number}: Single packet block for short broadcast messages in an MnW; 

— MC-FBS {block number}: WLAN compliant data transmission. 

13.8.2.4 The end of any one of these blocks shall be indicated by the MAC command MC-BLE. 

13.8.2.5 The start of every packet in a block, except the first packet, shall be indicated by the command 
MC-PAS. 

13.8.2.6 The end of every packet, except the last one of a block, shall be indicated by the command 
MC-PAE. 

13.8.2.7 Blocks and the related block numbers shall be released for new use as soon as error-free 
reception of a block is indicated by the MAC command MC-BAck. 

13.8.2.8 Erroneous packets shall be retransmitted on request of the recipient. A request for retransmission 
shall be indicated by the MAC commands MC-TNAck& or MC-TNAck or MC-RTQ, as applicable. 

13.8.2.9 If a MAC command does not imply handover of the communication token, i.e. the right to send, 
this shall be done using the MAC command MC-TKN, if applicable. If a station has no packet or command to 
send, it shall send immediately the MAC command MC-TKN in order to dynamically share the channel 
capacity between master and slave. 

13.9 Window management 

An application service shall be able to command free airtime. How this is achieved is outside the scope of this 
International Standard. 

13.10 IVIAC tunnel 

An application service shall be able to request transmission of MAC internal and manufacturer-specific 
commands and data to a peer station using the MAC command MC-SMC. How this is achieved is outside the 
scope of this International Standard. 



74 



IS 15754 : 2006 
180 21214:2006 



14 Adaptation 

14.1 Architecture 

Medium adaptation is a means to adapt the IR specific lower layers to the common CALM network and CALM 
management entity (CME). These lower layers include the physical layer and the data link layer, as well as an 
IR specific medium management entity IR-ME. The data link layer at least consists of the MAC sub-layer and 
the IR communication adaptation layer. The communication adaptation layer can be considered as an IR 
specific LLC. 

The medium adaptation is outlined in Figure 17. 
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Figure 17 — Medium adaptation 

IR-CAL provides a communication SAP to the CALM network layer following the same principles as outlined in 
ISO/IEC 8802-11:1999. 

IR-MAE provides management service access points (SAPs) to the CALM management entity following the 
same principles as outlined in ISO/IEC 8802-1 1 with respect to the station management entity. 

14.2 IR-CAL 

14.2.1 Connmunication SAP 

14.2.1.1 Reference 

The service access point towards the CALM network layer will be defined in a future International Standard 
(ISO 21217). It provides the two service primitives C/A-L/W/TDA 7/4.request {} and CA-L/MTDA 7A. indication {}, 
both with the parameters Source_Address, Destination_Address, data and priority. 



75 



18 15754:2006 
180 21214:2006 

14.2.1.2 Source_Address 

The Source_Address parameter is the concatenation of source SAP address and source MAC address. The 
MAC address is defined in 14.2.4. 

14.2.1.3 Oestination_Address 

The Destination_Address parameter is the concatenation of destination SAP address and destination MAC 
address. The MAC address is defined in 14.2.4. 

14.2.1.4 SAP addresses 

SAP addresses will be defined in a future International Standard (ISO 21218). 

14.2.1.5 Data 

The data parameter carries the N-PDU. 

14.2.1.6 Priority 

To be harmonised with other CALM media. 

14.2.2 Communication types 

14.2.2.1 CALM-fast applications 

Default mandatory communication in CALM-IR considers CALM-fast applications (CFAs). Each packet 
received from the CALM network layer in the CA-UNITDATA.request service primitive shall be treated as one 
IR block. 

Blocks may be associated with CALM data channels or with CALM control channels. 

Upon error-free reception of a complete block, the IR-CAL shall forward it to the CALM network layer using the 
C-A-L/A//TD/\TyA. indication service primitive. 

14.2.2.2 ISO/IEC 8802-11 compatible services 

These services are optional. 

For WLAN communication compliant with ISO/IEC 8802-1 1 , a separate entity of the IR communication 
adapter shall be created with a new MAC address and be reserved for this type of communication. The CALM 
management shall be informed about such an entity via the IR-MAE. Each packet received from the CALM 
network layer in the CA-C/MTDAT/\. request service primitive (see the future International Standard 
ISO 21217), shall be treated as one IR block. The IR-CAL shall generate required WLAN MAC header 
information and insert it at the beginning of each block. The start of a block shall be indicated by the MAC 
command MC-FBS. The related procedures for generation and processing of header information for 
transmission and reception are defined in 14.2.3. 

Upon error-free reception of a complete block, the IR-CAL shall evaluate the WLAN header information and 
then shall forward the remaining body to the CALM network layer using the C/A-t//V/TD>AT/A.indication service 
primitive (see the future International Standard ISO 21217). 
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14.2.3 WLAN functionality 

14.2.3.1 Basics 

In order to support the ISO/IEC 8802-11 mechanism for building and using BSSs with non-compliant media 
such as IR, the data normally generated and evaluated in the ISO/IEC 8802-11 MAC as part of the MAC 
procedures shall be treated as payload in the IR communication adapter. 

As the IR communication adapter has its own mechanism to manage the data flow on the link, 
ISO/IEC 8802-1 1 flow control information shall not be transmitted via the IR link. 

The IR communication adapter shall manage only data of the ISO/IEC 8802-11 frames which are needed to 
provide the services supported by ISO/IEC 8802-1 1 . 

All other information, such as data rate or others, is specific to the IR medium. 

14.2.3.2 Relevant information 

Relevant information, e.g. the BSSID of a BSS, shall be transmitted as payload following the MC-FBS 
command. Relevant information is explained in 14.2.3.2.1. 

14.2.3.2.1 Type 

The type of the ISO/IEC 8802-1 1 frame is relevant information. Only those ISO/IEC 8802-1 1 MAC frames for 
management and data described in Table 30 are supported by CALM-IR. 

Table 30 — IR type field description 



Type description 


IR type value 


Subtype description 


Management 


0000 


Association request 


Management 


0001 


Association response 


Management 


0010 


Reassociation request 


Management 


0011 


Reassociation response 


Management 


0100 


Scan request 


Management 


0101 


Scan response 


Management 


0110 


Join request 


Management 


0111 


Join response 


Management 


1000-1001 


Reserved 


Management 


1010 


Disassociation 


Management 


1011 


Authentication 


Management 


1100 


Deauthentication 


Reserved 


1101-1110 


Reserved 


Data . 


1111 


Data 



14.2.3.2.2 Frame control 

The two bits, to DS and from DS, as described in ISO/IEC 8802-11, are relevant information. 
The frame control is reduced to one octet size, as described in Table 31. 
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Table 31 — Frame control octet in IR 








Bit 





1 


2 


3 


4 


5 


6 


7 


Description 


(not used) 


WEP 


ToDS 


From DS 


IR type value ] 



Other communication control fields from ISO/IEC 8802-1 1 frames are not relevant to iR. 
14.2.3.2.3 Addresses 

The addresses 1-4 of an ISO/IEC 8802-11 frame shall be sent as described In ISO/IEC 8802-11 without the 
sequence control field between address 3 and address 4. 

The address fields Addr 2, Addr 3 and Addr 4 shall be transmitted only in cases as requested in Table 32. 

Table 32 — Address types for IR 



IR type 


ToDS 
value 


FromDS 
value 


Addr 1 type 


Addr 2 
type 


Addr 3 
type 


Addr 4 
type 


Description 


Data 








DA^ 


SA'' 


BSSiD<^ 


n.a. 


A data frame direct from 

one station to another 

station within the same 

independent BSS, as well 

as all management and 

control type frames. 


Data 





1 


DA 


BSSID 


SA 


n.a. 


Data frame destined for 
the distribution system. 


Data 


1 





BSSID 


SA 


DA 


n.a. 


Data frame exiting the 
distribution system. 


Data 


1 


1 


RA*= 


TA« 


DA 


SA 


Wireless distribution 

system frame being 

distributed from one 

access point to another 

access point. 


SCAN request 


n.a. 


n.a. 


SA 


n.a. 


n.a. 


n.a. 




SCAN response 


n.a. 


n.a. 


BSSID 


DA 


BSSID 


n.a. 


Addr 3 is used only in the 

event that the BSS 
provides an access point. 


JOIN request 


n.a. 


n.a. 


BSSID 


n.a. 


n.a. 


n.a. 




JOIN response 


n.a. 


n.a. 


BSSID/ 
0x000000 


n.a. 


n.a. 


n.a. 


Addr 1 equals 0x000000 in 

the event that the 

JOIN request is not 

accepted. 


Association, 

re-association, 

dis-association, 

authentication, 

de-authentication 


Use of addresses as defined in ISO/IEC 8802-1 1 


^ DA is the Final Destination Address. 

^ SA is the Source Address. 

•= BSSIDistheBasicServiceSetlD. 

^ RA is the Receiver Address. 

^ TA is the Transmitter Address. 
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14.2.3.3 WLAN block 



The relevant information to support ISO/IEC 8802-1 1 is transmitted in an IR specific frame header as 
described in Table 33. The'frame body carries the N-PDU and shall directly follow this header. 

Table 33 — ISO/IEC 8802-11 compliance header for IR frames 



Element 


MC-FBS 


MC-FBS 
attributes 


frame 
control 


Addri 


Addr2 


Addr3 


Addr4 


frame 

body 

(first 

fragment) 


MC-BLE 

or 
MC-PAE 


Size in 
octets 


1 


2 


1 


6 


6 


6 


6 


... (max. 
packet 

size- 
over- 
head^) 


1 


Contains 


IR 
command 


IR command 
attribute 


IR data 


IR 

command 


^ The overhead equals the size of the elements other than frame body fragments actually used. 



Table 34 — In the event of fragmentation used for 2nd up to last frame 



Description 


MC-PAS 


MC'PAS 
attributes 


frame body 

(subsequent 

fragment) 


MC'BLE or MC-PAE 


MC-BLE 1 MC-PAE 


Size in 
octets 


1 


2 


1 ... (max. packet 
size - 4) 


1 


1|0 


Contains 


Command 


Attribute 


Data 


Command 


Attribute 



14.2.4 MAC addresses 

14.2.4.1 Basics 

According to ISO/IEC 8802, a MAC address consists of six bytes, divided into two groups: the vendor value or 
manufacturer ID and the user value or station ID. Each consists of three bytes. The first bit (LSB) of the 
LS-Byte of the MAC address is the l/G-Bit, which describes whether the MAC address is an individual (=0) or 
a group (=1) address. The second bit is the U/L-Bit, which describes whether the MAC address is a universal 
administered (=0) or a local address (=1). The individual, universal administered address is always the 
adapter MAC ID. It is not possible to change this physical address, but it is possible to use a logical, individual, 
locally administered address. 

14.2.4.2 MAC addresses in CALM-IR 

The real identity of a CALM medium adapter is the physical MAC address assigned to this adapter. In IR 
frames for CFAs, this unique MAC address is not used. Instead of the unique MAC address, only a two byte 
temporary ID applies in the link. The unique MAC address may be used only in WLAN compliant links. 

in case of privacy on the medium: 

The private slave MAC address as used in the communication SAP is constructed as shown in Figure 18. 
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LS-Byte 


Byte1 


Byte 2 


Byte 3 


Byte 4 


MS-Byte 


Vendor value 


User value 


Individual, local 


Slave qualifier 


TempID 



Figure 18 — Slave MAC address 

In case a vendor value is not known at the receiving station, it shall be set to 0x000002. The slave qualifier is 
detailed in Clause 13. 

The private master MAC address as used in the communication SAP is constructed as shown in Figure 19. 



LS-Byte 


Bytel 


Byte 2 


Byte 3 


Byte 4 


MS-Byte 


Vendor value 


User value = Master identifier, MID 


Individual, local 


Master qualifier 


Identifier 



Figure 19 — Master MAC address 

In case a vendor value is not known at the receiving station, it shall be set to 0x000002. The master qualifier is 
detailed in Clause 13. 

The Broadcast MAC address as used in the communication SAP is constructed as shown in Figure 20. 



LS-Byte 


Bytel 


Byte 2 


Byte 3 


Byte 4 


MS-Byte 


Vendor value 


User value 


OxFFFFFF 


Master qualifier 


TempID = OxFFFF 



Figure 20 — Broadcast MAC address 

in case a vendor value is not known at the receiving station, it shall be set to OxFFFFFF. The master qualifier 
is detailed in Clause 13. 

14.2.5 Fragmentation and defragmentation 

CALM-IR may use shorter frames than required for IPv6, i.e.1 280 byte. Thus, a fragmentation procedure 
performed at the MAC, which is invisible to the upper layers, shall be implemented. Independent of the 
actually used frame length, the IR-MAE shall report a frame length of at least 1 500 byte to the CALM 
management; larger values shall be allowed dependent on the actual implementation. 

14.3 IR-MAE 

The service access point towards the CALM management will be defined in two future International Standards 
(ISO 21217 and ISO 21218). 
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15 Adoption of other standards and internationally adopted practices 

Within the various ITU regions, the family of CALM International Standards, including this International 
Standard, shall operate within local regulations and in the environment of, and to the parameters defined in, 
the relevant ITU regulations and International Standards. 

NOTE Adoption of other standards and internationally adopted practices will be presented in a future International 
Standard (ISO 21217). 
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16 Marking and labelling 

All transmitting equipment shall be clearly and permanently marked to state with which national regulations it 
complies. 

All transmitting equipment shall be provided with clear instructions as to tuning and adjustment to meet the 
regulations of the country in which it is to be used. 

All transmitting equipment shall be clearly and permanently marked to indicate which CALM interfaces it 
supports. 

All transmitting equipment shall be clearly and permanently marked to instruct that it shall only be used when 
adjusted to meet national radio regulations pertaining to the frequencies at which it operates. 
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17 Declaration of patents and Intellectual Property 



NOTE This form is to be used to record the statement of a patent holder whose patented device or design (pending 

or approved) may have to be used by a person or organisation complying with an ISO International Standard. 



Name of patent 
Holder: 

1 Inventors: 

Martin Aureliano 
Hassner, Mountain 
View, CA (US) 

Nyles Heise, San 
Jose, CA (US) 

Walter Hirt, Wettswil 
(CH) 

Barry Marshall 
Trager, Yorktown 
Heights, NY (US) 

Assignee: 

International Business 
Machines 

Corporation, Armonk, 
NY (US) 
Address: 



Telephone: 
Contact: 



Table 35 — Table of patents 
Jurisdiction, patent number and titie 

United" Slates Patent 

6,195,025, Hassner. et a!., February 27, 2001 



Methods and means for invertlbly mapping binary sequences into 
rate 2/3 (1 ,k) run - length - limited coded sequences with 
maximum transition density constraints 



International Business Machines Corporation 

Intellectual Property & Licensing 
North Castle Drive 
Armonk, New York 10504 



/AX: l?14).765-442p 



Director 

Intellectual Property & Licensing 

North Castle Drive 

Armonk, New York 10504 

FAX - Attention: Director of Intellectual Property &^U 
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Name of patent 
Holder: 

2 Inventors: 

Hassner; Martin (Mountain 
View, CA); 

Heise; Nyies (San Jose, CA); 

Hirt; Walter (Wettswil, CH) 

Assignee: 

International Business 
Machines Corporation 
(Armonk, NY) 
Address: 



Jurisdiction, patent number and title 

United States Patent 

6,344,807. Hassner. at al.. February 5. 2002 

Packet frame generator for creating an encoded packet frame 
and method thereof 



Telephone: 
Contact: 



International Business Machines Corporation 

Intellectual Property & Licensing 
North Castle Drive 
Armonk, New York 10504 



/AX: 1914)765-4420 



Director 

Intellectual Property & Licensing 

North Castle Drive 

Armonk. New York 10504 

E.^...:./^.!.!.^Dl'.9!?..J^^ P.[op.6rtY^ Licensing 



84 



Helmut Rieder 
Sijdtirolerplate 10 
8020 Graz 
Austria 



18 15754:2006 
180 21214:2006 



Name of patent 
Holder: 

3 Inventors: 



Raimund Pammer 
G he ska! 54 
8020 Graz 
Austria 

Wolgang Boh 
Durrgrabenweg 12 
8045 Graz 
Austria 

Andreas Schalk 
Mantschawaldweg 48 
8054 Graz 
Austria 



Jurisdiction, patent number and title 



PCT/EP03/05425 - "IR-Framing" 
23.05.2003 



The invention relates to a method and device for optical data 
transmission, in particular a method for transmission of data by 
means of digitised infra-red signals. Data sequences are 
transmitted using a time-division multiplex access protocol with 
communication frames comprising single sequential windows 
with a given minimal bit transmission rate. At least one control 
impulse sequence is provided in each communication frame. 
According to the invention, the control impulse sequence is 
transmitted at a bit transmission rate which is lower than the 
minimum bit transmission rate for the data sequence 



Assignee: 
EFKON AG 

Address: 



EFKON AG 

Andritzer Reichsstrasse 66 

8045 Graz 

Austria 



Telephone: 
Contact: 



+43 316 695675:0 
Legal Department 
Andritzer Reichsstrasse 66 
8045 Graz 
Austria 



FAX: 
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Annex A 

(normative) 

Coding and error correction of profiles and 1 and of commands 



A.1 General 

Alt information bits are protected by error correction bits (ECq, £Ci, EC2, EC^} using an advance Hamming 
code with the length Z = 12 and the Hamming distance of min. D = 3. The modification is done in order to 
avoid an "all zero" pattern for the benefit of the receiver. 

During transmission, the data bits in the sequence Dq. D^, D2, D^, D^, D^, Dg, Dj are always transmitted first, 
followed by the error correction bits ECq to ECy 



A.2 Coding 

The coding of the correction bits is according to the following formula: 

EC^ = DQ®D2®D^®D^®DQ 
£C2 = Z)i®Z)2®D5©Z)7 
EC2 = D2®D^®Dq®Dj 

A.3 Transmission 

The coded bits are transmitted as follows (least significant bit first): 



^0 


D, 


D2 


Dz 


^4 


^5 


^6 


Dj 


ECq 


EC-i 


EC2 


EC^ 



A.4 Reception and decoding 

After reception, the following syndrome is calculated over the received bits Rq to /?ii. The defect bits are 
shown in Table A.1 . 

Sq = Rq © /?i © /V2 © ^3 ® A4 © A g 
"1 ~ "0 2 4 ® 5 6 ® ■''9 

03 = JVT ® /? 4 ® Ag © Rj ® A^J -j 
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Table A.1 — Decoding table 



•^0 


S, 


^2 


^3 


Result 


1 


1 


1 


1 


all bits correct 








1 


1 


Rq defect 





1 





1 


/?i defect 











1 


i?2 defect 





1 


1 





/?3 defect 








1 





/?4 defect 


1 








1 


/?5 defect 


1 





1 





Rq defect 


1 


1 








^7 defect 





1 


1 


1 


Rq defect 


1 





1 


1 


Rq defect 


1 


1 





1 


R'^Q6e1e(A 


1 


1 


1 





R^ ^ defect 


any other combination 


multiple bit errors 
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Annex B 

(normative) 

Coding and modulation of profiles 2 to 6 



B.I General 

In the CALM-IR communications profiles 2 to 6, a special packet format {CALM-fast IR packet format - FCIR) 
based on the run length limited code (RLL) HHH(1, 13) is used. 

HHH(1,13) was especially developed for infra-red transmission links in order to take care of the specific 
properties of the medium infra-red and the components available for implementation. 

HHH(1, 13) has the properties given in Table B.I, which make it especially useful for IR-links. 

Table B.I — HHH(1, 13) properties 



Property 


Value 


Code rate 


2/3 


Maximal duty cycle 


1/3 {" 33 %) 


Average duty cycle 


~ 26 % 


Minimal duty cycle 


1/12 (-8.3%) 


Run length constraints 


(d.k) = (1.13) 


Longest run of '10's 


yyy'000'101'010'101'000'yyy 


Chip rate 


12 Mchips/s at 8 Mbit/s 

24 Mchips/s at 16 Mbit/s 

48 Mchips/s at 32 Mbit/s 

96 Mchips/s at 64 Mbit/s 

192 Mchips/s at 128 Mbit/s 



B.2 FC//? packet 

B.2.1 Packet format 

The FCIR packet has the following format which ensures efficient and effective decoding as well as proper 
synchronisation and error detection. 



Preamble (PA) 


Start (STA) 


Payload (PL) CRC 


Flush byte (FB) 


Stop (STO) 



B.2.2 Preamble 

The preamble PA ensures proper bit synchronisation even if the FCIR packet follows a MAC command that 
ends with a zero. 
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It is constructed by concatenating ten times the 24 clnip preamble period (PP), where 

pp = 'ioo'oio'oio'oorooroorooo'ioo' 

to form the 240 chip preamble 

PA = 'PP'PP'PP'PP'PP'PP'PP'PP'PP'PP. 
The left-most chip of PP and PA, respectively, shall be transmitted first. 

B.2.3 Start flag 

The start flag STA allows for packet synchronisation. 
STA is the 48 chip sequence: 

ST/\ = 'ioo'ioi'oio'ioo'ioo'oio'ooo'ooi'ooroio'ioi'oorooo'Ooroio'ooo'. 

The left-most chip shall be transmitted first. 

The start flag detector shall declare a flag as having been found when there is a perfect match. The flag 
contains a subsequence '1001010101001' that violates the HHH(1,13) code. This subsequence occurs twice 
in the start flag and never occurs within the main HHH code. 

B.2.4 Payioad 

The payioad PL is the CALM-IR packet which follows one of the MAC commands MC-BLS, MC-CBS, 
MC-FBS, MC-SMC, MC-PAS, MC-TAck&, MC-TNAck&, MC-SR1. MC-SR2, MC-SR3, MC-SR4. 

The CRC32 for the CALM-IR packet shall be calculated before the CALM-IR packet is scrambled. 

B.2.5 Cyclic redundancy check 

The frame check sequence (PCS) field is a 32 bit field that contains a cyclic redundancy check (CRC) value 
according to the IEEE 802 CRC32 algorithm. 

For reference, the CRC32 polynomial is defined as follows: 

CRC(X) = x32 + ;f26 + ;f23 + ^22 + jf 16 + ;f12 + ^1 1 + ^10 + ;f8 + ^7 + ;(5 + x4 + x2 + X + 1 . 

The CRC is a calculated, payioad data dependent field, calculated before HHH(1,13) encoding. 

Payioad data bytes are input to this calculation in LSB first format. 

The 32 bit CRC register shall be preset to all "1's" prior to calculation of the CRC. 

The CRC32 calculated result for each packet is treated as four data bytes, and each byte is encoded in the 
same fashion as is payioad data, e.g. it shall be appended to the CALM-IR packet before being scrambled 
and HHHCf, 73; encoded. 

B.2.6 Flush byte 

The flush byte FB is required to enable complete decoding of the CRC field and denotes the end of the main 
body. 

FB is the 8 bit sequence FB = 'OO'OO'OO'OO'. It shall not be scrambled and shall be appended to the CRC 
before HHH(1, 13) encoding. 
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B.2.7 Stop flag 

The stop flag STO indicates the end of the FCIR packet. 
STO is the 48 chip sequence: 

STO = 'ooi'ooi'oio'iorooi'ooo'ioo'ooo'ioo'ioroio'ioo'ioo'ooo'ioo'ooo'. 

As does the start flag, the stop flag also contains a subsequence '1001010101001' that violates the 
HHH(1,13) code. This subsequence also occurs twice in the stop flag. 

B.2.8 Scrambling and descramb^ing 

B.2.8.1 Effects and limits 

By enhancing the system with scrambling/descrambiing functions during data transmission/reception, one 
achieves generally better duty cycle statistics in the HHH(1, 13) coded channel chip stream; the resulting duty 
cycle converges towards the average duty cycle of the code (- 26 %) for typical payload data. It is important 
to note that scrambling cannot entirely eliminate possible worst-case duty cycle patterns in the transmitted 
signal stream that can result from certain specific input data sequences. However, scrambling can greatly 
reduce the probability of occurrence of such worst-case patterns, 

Q.2.8.2 Scrambling and descrambliug functions 

The primitive polynomial 

xS e x^ 9 x3 © x2 © 1 , 

where © indicates a modulo-2 addition or, equivalentiy, a logic exclusive OR (XOR) operation, shall be used 
for implementing these functions. 

The operations of the scrambling and descrambling functions shall be performed according to the principles of 
frame synchronised scrambling/descrambiing (FSS) mechanisms. 

NOTE FSS does not introduce memory into the signal path, i.e., FSS does not increase the encoding/decoding 

delay and it does not aggravate error propagation in the decoded data stream. 

B.2 8.3 Scrambler/descrambler initialisation 

a) Transmit mode: 

The scrambler's shift register shall be initialised with the all-1 state, that is 
(xg, X7, xg, Xg, X4, X3, X2. xd = C. 1- 1. 1. 1. 1. 1. 1)- 

b) Receive mode: 

The descrambler's shift register shall be initialised with the all-1 state, that is 
(Xg, X7, Xg, X5, X4, X3, X2, Xi) = (1,1,1,1,1, 1. 1, 1). 
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B.2.9 HHH(1,13) encoding and decoding 

B.2.9.1 State transition table 

The encoding definition of the HHH(1, 13) code is provided by a state transition table. 

The state transition table would be typically implemented as a set of boolean logic equations and flip flops. 

The particular HHH(1,13) code construction requires the following interpretation of the table entries with 
respect to the mapping of internal inputs and present state into next state and internal output, respectively: 

— A specific data pair D^D* = {S^, S2) arriving at the encoder input is first associated with a corresponding 
next state N = N*. This occurs as soon as the data D* have advanced into the positions of the internal 
data bits S"* = (6^, ^2)' '•^•' when (b.^, bj- bj, b^, b^, bg) = {S^, S^, x, x, x, x). In a second step, during the 
next encoding cycle, the state S takes on the value of ft, i.e., S s S* ■<- A/* so that S is now associated 
with {(\, 62). In the same cycle, the inner codeword C 2= C" now carrying the information of D* is computed. 
Thus, referring to Table B.2, a given internal input vector {b^, i)2- ^^'3. b^. jbg, bg) associates the bits (b-|, ^2) 
with the next state N and a given state S associates the data pair ahead of (/?.), ^2) with the output C. In 
other words, the pair-wise values for N and C as listed in Table B.2 are not associated with the same 
input data pair. 

■~~ Encoder initialisation: The state S = (Si, S2, S3) = (1,0, 0) is also used as the initial state of the encoder, 
i.e . denoting with {a, /?) the first pair of data bits to be encoded, the state S is forced to take on the value 
(1, 0, 0) when the bits {«, /^ have advanced into the encoding circuits such that the internal inputs 

B-^[b^,b^j)s{a,(j), 

Table B.2 ~- HHH(1,13) encoding state transition table 



Present state: 




Next state/internal output: N = (n^, n^, 


n^)IC = {c^, 


C2, C3) 








Internal inputs: {b^, bj- ti-^: b^ 


,b,.b,) 






OOxxxx 


Olxxxx 


lOxxxx 


IIOOxx 


11 01 XX 


111011 


1110(11) 


mixx 


000 


000/010 


001/010 


010/010 


111/010 


100/010 


111/010 


011/010 


011/010 


1 


000/001 


001/001 


100/001 


100/010 


111/101 


100/010 


100/010 


100/010 


01 


000/100 


001/100 


010/100 


111/100 


100/100 


111/100 


011/100 


011/100 


01 1 


000/101 


001/101 


100/101 


100/100 


011/000 


100/100 


100/100 


100/100 


1 00 


000/000 


001/000 


010/000 


011/000 


011/000 


011/000 


011/000 


01 1/000 


1 1 1 


100/000 


100/000 


111/000 


100/000 


100/000 


100/000 


100/000 


100/000 



NOTE 



The state (s., Sj, So) = (1,0, 0) is the required initial state during the one encoding cycle where the internal 



input pair B^ " (b.. b^) represents the first data pair to be encoded; 'x' signifies don't care. 

B,2.9.2 HHII(1, 13} encoding equations 

The state transition table above can be implemented as a set of encoding equations as below. 

Define the following encoder signal vectors where increasing indexes mean increasing time in the equivalent 
serial signal streams: 

Data input: D = {d\ cfi) 

NOTE First data input to be encoded: D = {a, /7). 
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Present state: S = {s^, S2, S3) 

Next state: N = (n^, n^, n^) 

Internal data; B^ = (B\, B\) = (b^, b2) 

B2 = (B\ B\) = ib^, b^ 
B3 = (B\ By = (bs, be) 

Internal codeword: C = (c^, C2, c^ 

Encoder output: y=(Y^,Y2,Y2) 

Initial conditions (start up): S = (s^, Sj, S3) = (1,0, 0) when S^ = (f)^, 62) s D = {a, fi) 

With the boolean operator notation, 
m=INVERSE{m), 

m + n = mOR n, 

mn = m AND n, 

the components of N and C are computed in terms of the components of S, B\ B^, and B^ with the following 
boolean expressions: 

n^ = (S1S3) + (S3/31) + (Sit»ib2^3) + is^b^b2t>Ab5^6) ■ 

n2=(S3Jbi) + (SiS2/)ib2), 
/^3=(S3jb2) + (SibiiJ2) + (SlS2^1^2)- 



C2 =5^5203 , 

C3 =SiS3(bi+ 62) + (51536162^364). 

The vectors B\ B^, B^, S, and Yare outputs of latches; in every encoding cycle, they are updated as follows; 
ei ^ 62 <- b3 <- D, 

S <- A/, and Y <- C 
B.2.9.3 HHH(1, 13) decoding equations 

The decoding function of the HHH (1, 13) is defined by the following equations;. 
NOTE Increasing indexes mean increasing time in the equivalent serial signal streams. 
Received codeword; R = {r^, ^, fi) 
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Internal codewords: 



v''=(yio.yii,/i2) 
y^=(y7'y8,y9) 
v^=(y4-y5.y6) 
v^ = (yi,y2.y3) 



Internal variables: 



Ze=y4+y5+/6 

^c^yy+ys+yg 



2D = yio+yii+yi2 

V=(V/1,V2) 

Decoder output: U={u^, U2) 

Initial conditions (start up): None 

The components of X^, X^, and X^ are computed with the following boolean expressions: 

Xi=Vi 



X2=iy6^c) + iZBZcZD) + V2 

X3 - (ZbZcZd ) + (Z^Zc ) + Wi + IV2 

x4 = (ZBZcZ;^y3)+[ZeZc(ZD + y6)]+w2 

The vectors yi, V^, V^, V*, U, V, and IV are outputs of latches; in every decoding cycle they are updated as 

follows: 

W^ X^, l/<-X2, 1(4- Xl, 

where U represents the decoded data bit pair. 

NOTE Both Zg and Zq can be directly obtained from delayed versions of Zq. Zq^Zq*- Zq. 
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B.2.10 Fast packet processing: summary 

Figure B.2 shows the complete CALM-fast IR packet {FCIR-packef) construction process. 



CALM-IR packet 



compute CRC 



CALM-IR packet 



GRC 



scramble 



scrambled CALM-IR packet and CRC 



I 
append flush byte (FB) 

i 



scrambled CALM-IR packet and CRC 



\ 
Encode 

1_ 



FB 



HHH( 1, 73) encoded CALM-IR packet, CRC and FB 



append leading STA and PA and trailing STO 


PA STA 


Payload PL 


CRC 


FB 


STO 




' 






transmit 





Figure B.1 — CALIVI-fast IR packet processing 
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Annex C 

(informative) 

Link power budget 



C.I Genera) 

The link power budget has to take into account both directions, master to slave and slave to master, 
considering a non-symmetrical link having transmitters with different power and receivers with different 
sensitivity at the ends of the link. 

There are both economical and technical reasons to have non-symmetrical links. In general, on-board units 
(OBUs) should be economically priced, as normally many more OBUs are used than roadside units (RSUs). 
That means that OBUs have transmitters with lower power than RSUs and, on the other hand, the receiver 
sensitivity of the RSUs shall be increased to achieve power balance in both directions. 

In addition to this, OBUs are often battery powered and should therefore employ lower power transmitters. 



C.2 Link power budget definitions 

C.2.1 Link distance 

The link distance d is the distance between the communication devices in metres. 

C.2.2 Transmission losses 



All losses (L) are expressed in decibels: /. [dB] = 10 • log 



^out 



Transmission losses (Ljp) consist of path loss and additional losses: ijR = Lp +Lfi^Q 

C.2.3 Path loss 

The path loss (Lp) is the distance-related loss, without any lossy media between transmitter and receiver: 

Lp =^0■\ogD^, 
where 

/) = c//1 







Table C.1 — Path loss In 


relation to 11 


nk distance 






Path loss 


10 


20 


50 


Link distanc 

m 
100 


200 


500 


1000 


LpidB] 


20 


26 


34 


40 


46 


54 


60 



95 



1815754:2006 
180 21214:2006 

C.2.4 Additional losses 

C.2.4.1 Additional losses are calculated as follows: 

where 

L^ are losses due to windscreen and sun protection (coating or foil); 

L\j^Q are losses due to weather conditions (rain, snow and fog); 

Z-suN ^i'® losses due to sunlight. 

C.2.4.2 IR loss measurements on all kinds of windscreens have been investigated from many 
independent institutions. All the windscreens measured so far were evaluated to be below 7 dB (most in the 
range 1,5 dB to 5,5 dB). 

C.2.4.3 IR loss measurements under many weather conditions have been investigated from many 
independent institutions, The relevant results are given in Table C,2. 

Table C.2 — IR loss under different weather conditions 



Weather 
condition 


10 m 


infra 

20 m 


■red loss i 

50 m 


it various 

dB 

100 m 


link dista 

200 m 


noes 

500 m 


1000 m 


Clear weather 


<1 


<1 


<1 


<1 


<1 


<1 


<1 


Light rain 


<1 


<1 


<1 


<1 


<1 


1 


2 


Heavy rain 


<1 


<1 


<1 


1,5 


3 


7,5 


15 


Fog 


<1 


<1 


4 


8 


16 


40 


80 


Dense fog 


<1 


1,6 


8 


16 


32 


80 


160 



C.2.4.4 Sunlight-induced losses can, by proper receiver design, be kept below 2 dB, even against full 
sunlight. 

C.2.4.5 The additional losses (especially the weather conditions) shall be considered in view of several 
realistic scenarios. 

— Heavy rain and fog do not occur simultaneously. 

— Full sun does not occur with bad weather. 

— Sun-protected windscreens ("coated windscreens") reduce also the sun-induced losses. 

C.2.5 Symmetrical and non-symmetrical links 

The physical layer of an infra-red CALM link may be either "symmetrical" or "non-symmetrical", the choice of 
which is chosen according the application requirements. 

In a "symmetrical link", the transmitter power parameters as well as the receiver sensitivity parameters of both 
communications partners are equal, whereas in "non-symmetrical" links those parameters differ. 
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In order to support a proper selection for a given application or a class of applications, the relevant transmitter 
and receiver parameters are organised in "transceiver classes". 

C.2.6 Transmitter/receiver combinations 

Table C.3 gives the achievable distances (without considering "additional losses") in free space. 

Table C.3 — Achievable distance for different combinations of RX and TX classes 



TX class 


R1 


R2 


R3 


Achiev 

R4 


rable dis 

R5 


stance f< 

m 

R6 


)r a give 

R7 


n RXcU 

R8 


iss 

R9 


R10 


R11 


T1 


1.25 


1,75 


2,5 


3.5 


5 


7 


10 


14 


20 


28 


40 


T2 


1,75 


2,5 


3,5 


5 


7 


10 


14 


20 


28 


40 


56 


T3 


2.5 


3,5 


5 


7 


10 


14 


20 


28 


40 


56 


80 


T4 


3.5 


5 


7 


10 


14 


20 


28 


40 


56 


80 


110 


T5 


5 


7 


10 


14 


20 


28 


40 


56 


80 


110 


160 


T6 


7 


10 


14 


20 


28 


40 


56 


60 


110 


160 


250 


T7 


10 


14 


20 


28 


40 


56 


80 


110 


160 


250 


350 


T8 


14 


20 


28 


40 


56 


80 


110 


160 


250 


350 


500 


T9 


20 


28 


40 


56 


80 


110 


160 


250 


350 


500 


700 


T10 


28 


40 


56 


80 


110 


160 


250 


350 


500 


700 


1000 


T11 


40 


56 


80 


110 


160 


250 


350 


500 


700 


1000 


>1000 


T12 


56 


80 


110 


160 


250 


350 


500 


700 


1000 


>1 000 


>1000 


T13 


80 


110 


160 


250 


350 


500 


700 


1 000 


>1 000 


>1 000 


>1000 


T14 


110 


160 


250 


350 


500 


700 


1000 


>1000 


>1 000 


>1000 


>1000 


T15 


160 


250 


350 


500 


700 


1 000 


>1000 


>1000 


>1 000 


>1 000 


>1000 


T16 


250 


350 


500 


700 


1000 


>1000 


>1000 


>1000 


>1000 


>1000 


>1000 



NOTE As the sensitivity is related to the noise floor and the noise floor depends on the square root of the receiver 
bandwidth, all tables are based on a specific data rate. Changing the data rate will influence the receiver sensitivity. 

C.2.7 Transmission margin 

The transmission margin is the margin for alt additional losses Lf^Q in decibels. 

C.2.8 Receiver dynamic range 

The receiver dynamic range Rq is the maximum irradiance profile the receiver shall be able to handle in 
relation to the minimum irradiance, calculated by 

i?D=10log^^?^2!9LidBl. 



97 



18 15754:2006 
180 21214:2006 

where 

£/^ rnax '^ ^^^ maximum irradiance, 

^R,m\n 's ^^^ minimum irradiance. 
C.2.9 Link power budget calculation examples 
C.2.9.1 Example 1 
We assume a given OBU with the following characteristics: 

OBU receiver irradiance minimum sensitivity: ^rt.min obu - 8 mW/m^ 

OBU transmitter radiant minimum intensity: 4 min OBU ~ 6 W/sr 

We want to calculate the minimum RSU parameters "transmitter radiant minimum intensity" and "receiver 
irradiance minimum sensitivity". 

Other given values are: 

Link distance: d= 20 m 

Additional losses 

Windshield with sun protection coating: ^w = ^ ^^ (max.) 

Weather condition (rain, snow and fog): jr, = 4 dB (max.) 

Sunlight-induced noise: ^^ 2 dB 



L 



SUN- 



Calculated loss values: (from above) 

Path loss: Lp= 26 dB 

Additional losses: ^ad= 13 dB 

Total transmission losses: ijp = 39 dB 



Calculation of the minimum irradiance profile at the RSU receiver (£/fmin)" 



TR 



R 

£c_RSU = /e,min_OBU 10 ^° = 39" "^ ^-^e.min.RSU =0.75 mW/m^ 

1010 

Calculation of the radiant minimum intensity of the RSU transmitter {En ^|n): 
It's the way back: 

/-TR 39 

^.,min_RSU=£/^,min_OBu''0 10 = 0.008 • 10 1° -> /,,^in_RSU =63.5 W/sr 

C.2.9.2 Example 2 

Now, as we have selected all transmitter and receiver classes we want to calculate the maximum distance the 
OBU-RSU pair can span. 
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This maximum distance is the lower value of the distance OBU ^ RSU and RSU -> OBU and is calculated as 
follows. 

1. Direction OBU -^ RSU 

OBU radiant intensity: 6 W/sr 

RSU receiver sensitivity: 0,5 mW/m^ 



;. = _k= ^-—- =109,54 m 

^£, \0,5-10-^ 

2. Direction RSU -> OBU 

RSU radiant intensity: 1 00 W/sr 

OBU receiver sensitivity: 8 mW/m^ 



100 



'■2 =j-^ = j:r^ -111.8 m 



^ d = min. (r^ , rj) = 109.54 m 
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C.2.10 Link power budget scheme 



Forward Jink 



Return link 



e.g. RSU to OBU 



e.g. OBU to RSU 



SwK^ 



RSU 
Minimum radiant intensity 



Lp Path loss 



no sunlight 



direct sunlight 



Z-AD Additional losses 



/?Qf^ Residual gain margin 



OBU Receiver irradiance 
minimum sensitivity 



RSU Receiver irradiance 
minimum sensitivity 



Rqm Residual gain margin 



L AD Additional losses 



no sunlight 



direct sunlight 



Lp Path loss 



6 



OBU 
Minimum radiant intensity 



Figure C.I — Link power budget scheme 
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Annex D 

(informative) 

Link directivity considerations 



D.1 General 

For a directional communication with CALM devices, a three-dimensional co-ordinate system (^calm- ^'calm- 
^caim) ^^s *° ^^ constituted. The origin of the co-ordinate system corresponds to the source of the beam. The 
X-axis of the CALM device is defined as the main direction. 

Figure 4 shows the azimuth angle ^ and the elevation angle J of the beam axis D (bore-sight direction) in 
relation to the main direction. 

Further parameters of directivity are the horizontal opening angle 9^^ and the vertical opening angle 0^, which 
are specified in relation to the beam axis D, see Figure 5. 



D.2 Multi-beam antenna example 

Figure D.1 shows an example of a multi-beam antenna and the related control parameters. 
The direction control parameters in this scenario are defined as follows: 

D-i ■^{(p^,(^, 0HJ, 0s/ i) 
D2 = {(P2><^2' ^H,2' ^V,2) 




Figure D.1 — Multi-beam antenna 
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D.3 Communication zones shortcut illustration 

Figures D.2 and D.3 show examples of the communication zones in the side and ground view respectively 
The zone names used are the shortcuts as defined in Tables 1 1 and 10. . h *-i vc.y. 



;";"ci> 




Figure D.2 — Side view of communication zones 




Figure D.3 — Ground view of communication zones 
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Annex E 

(informative) 

Compatibility of CALM and non-CALM infra-red systems 



E.1 General 

There exist a number of non-CALM-IR systems within the global ITS environments, some of them close to 
CALIVI-IR, some completely proprietary. 

Examples are the IRVD in Japan, the Malaysian road tolling system and the truck tolling system in Germany. 

When defining this International Standard, it was one of the essential requirements that the above systems be 
able at least to co-exist with CALM-IR without harmful mutual interference even if using the same optical band 
in overlapping communication zones and that, under certain conditions, a migration path from those systems 
towards a full CALM-IR system be feasible. 



E.2 Co-existence 

E.2.1 Creating free airtime for non-CALM-IR users 

In order to enable adequate co-existence for non-CALM-iR systems residing in the same or overlapping 
communication zone, any CALM-IR master (either residing on the roadside or in a vehicle) grants free airtime 
to all non-CALM-IR equipment coming along as follows. 

— The CALM-IR master does not use every CALM-IR window for CALM-IR communications, but leaves a 
certain window "empty" in order to enable this airtime to be used by other systems without any 
interference with CALM-IR. 

— In order to signal to the active CALM-IR slaves that a window shall not be used for CALM-IR 
communications, the CALM-IR master includes a "compatibility window" in the FOT. 

— The compatibility window remains unused by CALM-IR units; the airtime may be used by non-CALM-IR 
systems provided there exists a synchronisation mechanism between CALM-IR and non-CALM-IR 
systems. Possible synchronisation methods are described in E.2.2. 

— When the compatibility window has terminated (marked by the W-Sync issued by the CALM-IR master at 
its end), all control automatically falls back to the CALM-IR master. 

E.2.2 Synchronisation of CALM-IR and non-CALM-IR systems 

E.2. 2.1 Synchronisation principle 

There are two key issues when synchronisation between CALM-IR and non-CALM-IR systems Is required. 

— The non-CALM-IR system must be able to recognise that a CALM-IR master has created "free airtime" for 
"non-CALM" use. This function can be performed either "by wire" (in case both masters are fixedly 
installed and colocated) or "via air", either by using a synchronisation signal to be emitted by the CALM-IR 
master or implicitly, if the non-CALM-master can interpret the CALM-IR frame; 



103 



1815754:2006 
ISO 21214: 2006 

— The specific non-CALM-IR system must be able to recognise that the "free airtime" is dedicated to it. This 
step can be performed by a specific synchronisation signal, reserved for the specific "non-CALM" system, 
emitted 

— either by the master of the "non-CALM" system (in case step 1 had been performed "by wire"). 

— or by the master of the CALM-IR system after the W-Sync marking the compatibility window. 

E.2.2.2 Creation of sufficient airtime for non-CALIVI-IR systems 

It is evident that the compatibility window uses airtime of the frame. 

If even the longest allowed frame is occupied by too many private windows so not jsufficient airtime can be 
granted to the non-CALM-IR system, the CALM master may suspend some or all CALM-IR slaves in order to 
be able to allocate a sufficiently long compatibility window. 

Of course, this need not be done in each consecutive frame (this would disable all CALM-IR communications), 
but with a repetition rate adequate to the overall system requirements. 

To suspend the slaves, the MAC commands MC-SUS or MC-SUA may be used. 

E.2.2.3 Reserved synchronisation pattern 

At the time of developing this International Standard, four non-CALM infra-red systems which may coreside 
with CALM-IR in the ITS domain are known: 

— Japanese IRVD system, 

— German truck tolling system, 

— Malaysian road tolling system, 

— IrDA interfaces. 

The subsequent patterns have been selected after a careful study of the above-listed systems: 

Table E.I — Reserved ID patterns for non-CALM-IR systems 



System 


Frequency 


Cycles 1 


Japanese IRVD system 


Not applicable as no overlapping 
of beacon communication zones 
[according to E.2.2.4, f)] 


German truck tolling system 


85 kHz 


4 


Malaysian road tolling system 


85 kHz 


4 


IrDA interfaces 


tbd 


tbd 



E.2.2.4 Limitations and restrictions 

In order to avoid any harmful mutual interference between coresiding CALM-IR and non-CALM-IR systems, 
the following conditions shall be fulfilled. 

a) The non-CALM system shall not use any signal or code which could be misinterpreted as CALM-IR 
F-Sync or W-Sync. 

b) The non-CALM system shall not respond to a CALM-IR F-Sync or W-Sync. 
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c) The frame of the non-CALM-!R system shall not be longer than 64 ms in order to fit in the longest 
possible free airtime a CALM-IR system can grant. 

d) The CALM-IR system shall grant, as a minimum, a free airtime long enough for the maximum frame of the 
non-CALM system as long as condition c) is met. 

e) Non-CALM-IR masters installed in vehicles shall recognise the synchronisation pattern assigned to their 
system and shall consider the following airtime as assigned to the non-CALM system. 

f) To allow IRVD and CALM-IR to exist together, they shall be installed so that their beacon 
communications areas may not overlap one another, regardless of a) to e). 
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{Continued from second cover) 

Attention is drawn to the possibility that some of the elements of this standard may be the subject 
of patent rights. Bureau of Indian Standards shall not be held responsible for identifying any or all such patent 
rights. 

For the purpose of deciding whether a particular requirement of this standard is complied with, the final value, 
observed or calculated, expressing the result of a test or analysis, shall be rounded off in accordance with 
IS 2 : 1 960 'Rules for rounding off numerical values (rewseaf)'.The number of significant places retained in the 
rounded off value should be the same as that of the specified value in this standard. 
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